Bitcoin 0.3 almost ready -- please test the Mac version!
2010 Jun 22
See all posts
Bitcoin 0.3 almost ready -- please test the Mac version! @ Satoshi Nakamoto
- Author
-
Satoshi Nakamoto
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
Satoshi Nakamoto
0.3 almost ready -- please test the Mac version!
June 22, 2010, 04:01:53 AM
I finished everything on my list to do for version 0.3. The code on
SVN is about ready to release.
Testing at this point is much appreciated.
HostFat
June 22, 2010, 04:06:45 AM
I'm just here 
Windows 7 x64
4 GB RAM
Intel i7 860
lachesis
June 22, 2010, 06:20:02 AM
Very nice! There have definitely been some major improvements,
including the hashmeter, RPC support, and a command-line daemon. It
would be nice if the listtransactions RPC method were finished before
the next release, though. Also, some code should be added to the
JSON-RPC methods to list out dHashesPerSec.
Great work Satoshi!
Xunie
June 22, 2010, 07:28:56 AM
Whoohoo! Can't wait!
Note, is there somewhere I can get a devel build?
Maybe we can setup nightly builds or something...
teppy
June 22, 2010, 02:15:24 PM
Should we try for some publicity? Slashdot is good if we can get
it.
I've had a number of submissions accepted, though always by one
editor that no longer works there. Anyone else with a Slashdot
connection?
sirius
June 22, 2010, 02:20:31 PM
Quote from: teppy on June 22, 2010, 02:15:24 PM
Should we try for some publicity? Slashdot is good if we can get
it.
I've had a number of submissions accepted, though always by one
editor that no longer works there. Anyone else with a Slashdot
connection?
We should try to get publicity, and focus the campaign on the time
right after the release to get the maximum impact: simultaneously
advertising on forums, irc, Youtube, Facebook, Google Ads and other
places. Slashdot with its millions of tech-savvy readers would be
awesome, perhaps the best imaginable! I just hope the server can stand
getting "slashdotted" 
Maybe it should be upscaled beforehand just in case.
Satoshi Nakamoto
June 22, 2010, 05:02:07 PM
Quote from: lachesis on June 22, 2010, 06:20:02 AM
It would be nice if the listtransactions RPC method were finished
before the next release, though.
My fear is too many programmers would latch onto that for checking
for received payments. It can never be reliable that way. The
list/getreceivedbyaddress/label functions are the only way to do it
reliably.
We shouldn't delay forever until every possible feature is done.
There's always going to be one more thing to do.
Satoshi Nakamoto
June 22, 2010, 05:37:08 PM
Here's RC1 for windows for testing:
(removed, see RC2 below)
Please only download this if you're going to test and report back
whether everything seems fine or not. Make sure to look through the
files in "c:files"
Gavin Andresen
June 22, 2010, 05:58:56 PM
Quote from: satoshi on June 22, 2010, 04:01:53 AM
I finished everything on my list to do for version 0.3. The code on
SVN is about ready to release.
Testing at this point is much appreciated.
I just finished creating a clean Amazon EC2 debian 5.0 machine image
with everything I needed to compile bitcoind, and it compiled (using a
variation of Laszlo's makefile.unix) and is running fine (just finished
downloading the block chain). I'll let you know if it misbehaves.
I had trouble compiling the gtk version, but I think that's because I
did something wrong compiling wxWidgets. I don't need no stinkin'
graphics (and am not a wxWidgets expert), so I'm not going to bother
trying to fix that.
HostFat
June 22, 2010, 07:08:09 PM
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()
I have the same problem :|
Satoshi Nakamoto
June 22, 2010, 07:11:41 PM
Quote from: davidonpda on June 22, 2010, 06:23:26 PM
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()
What operating system?
Normally when it does that it's because the directory where the data
directory should go doesn't exist. See if the "%appdata%" directory
exists.
Do you get that error with 0.2 also? It's hard to see how you could
get that with 0.3 and not with 0.2 since there's nothing different in
that regard.
HostFat
June 22, 2010, 07:14:39 PM
Windows 7 x64 ENG
4 GB RAM
Intel i7 860
I was using the v0.2.10 build by laszlo before yours.
Satoshi Nakamoto
June 22, 2010, 07:25:13 PM
davidonpda, were you also running laszlo's build previously?
Check if the "%appdata%" directory exists, and "%appdata%"
Try:
rename "%appdata%\bitcoin" bitcoin2
does it work then?
HostFat
June 22, 2010, 07:33:24 PM
Quote from: satoshi on June 22, 2010, 07:25:13 PM
Check if the "%appdata%" directory exists, and "%appdata%"
Both are existing 
Quote from: satoshi on June 22, 2010, 07:25:13 PM
Try:
rename "%appdata%\bitcoin" bitcoin2
does it work then?
Yes it works.
so I closed it, copied the walled.dat from the old folder to the new
one, and now it's downloading blocks
Address book and old transfers seem ok, but there aren't anyone of old
"generated coins" ... I just need to wait?
Anyway, I can just go back with the old v0.2.10
EDIT:
I did another thing.
Closed it, copied addr.dat / blk0001.dat / blkindex.dat from old folder
to the new one.
Restarted bitcoin ( v0.30 ), and now it seems that everything is
working. ( I can see also old generated coins now )
I just did NOT copied "log.0000000002" from the database folder ...
Satoshi Nakamoto
June 22, 2010, 07:46:23 PM
You figured it out faster than I could post a reply.
It looks like laszlo's build of Berkeley DB has database/log.* files
that are not compatible with ours. The .dat files are fine, their
format shouldn't ever change. All data is stored in the .dat files.
All your own data is stored in wallet.dat. If you had waited for it to
redownload the block chain, your missing transactions and generateds
would have appeared as the block chain reached the point where those
transactions were recorded.
When you copied the directory except log.0000000002, that's the best
solution. You should be good now.
The database/log.* files only contain temporary database data. If
you exited bitcoin normally the last time, not exited by forced
terminating it or crashing, then the database/log.* files can normally
be deleted safely. They're only used so that if the database is in the
middle of a transaction when the computer crashes or the program is
killed or crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don't go back to
v0.2.10.
Anyone else who hits this problem, move the database.000000000* files
somewhere else. (if it works fine after that, you can delete them
later)
I'm reluctant to make the installer delete or move those files. If
the previous run was stopped by crashing or killed, that would be the
wrong thing to do.
HostFat
June 22, 2010, 07:49:50 PM
yes, I'm just using 0.30 by now.
Thank you!
D҉ataWraith
June 22, 2010, 09:01:58 PM
Runs fine under WINE. rhymes
It automatically switched the language to German, too. Now that I can
see the translation in the client itself, I noticed a few things to
improve, and will post a new .po file within the next two or so
days.
lachesis
June 22, 2010, 10:00:47 PM
Yeah, 0.3.0 seems to have a performance increase over svn r84 with
Laszlo's performance patch.
Satoshi Nakamoto
June 22, 2010, 10:23:39 PM
Laszlo figured out that enabling some more optimisation increased
performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume
he used that in his own build.
30khash increase to what total rate? (to figure the % increase)
Vasiliev
June 22, 2010, 11:07:30 PM
Much faster than Laszlo's build for me. Went from 600-700khash/s to
1000-1100khash/s on my Intel Core 2 Duo E8500. From 700-800khash/s on a
laptop i7 to ~1100khash/s.
edit: Keeping the "Run Bitcoin" option checked in the installer seems
to run it with admin privileges on the first launch. (in Win7)
Satoshi Nakamoto
June 24, 2010, 05:40:05 PM
Here's RC1 for linux for testing:
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile
bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to
get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the "-mt" from their filenames in
1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu
Karmic, you would need to change it back to boost_system-mt and
boost_filesystem-mt.
virtualcoin
June 24, 2010, 08:49:24 PM
Nice. :-)
64-bit version works fine on Ubuntu 10.04, of course it's (much)
faster than through WINE emulation (and because it's 64-bit!?)
4 cores: 2850 khash/s
3 cores: 2130 khash/s
2 cores: 1420 khash/s
1 core: 700 khash/s
WINE (32-bit):
4 cores - 2300 khash/s
3 cores - 1740 khash/s
2 cores - 1150 khash/s
1 core - 580 khash/s
Thank you - looks pretty nice, too.
http://i50.tinypic.com/2ih1h0p.jpg
edit: What's the difference between "Sent/Received" and "All
transactions"?
HostFat
June 24, 2010, 10:19:34 PM
will it change something if you release a x64 bit version for
Windows?
Vasiliev
June 24, 2010, 11:26:03 PM
Ubuntu 9.04 x86:
vlad@vlad:~/bitcoin/bin/32$ ./bitcoind\
./bitcoind: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)
Anybody know what Bitcoin needs?
Satoshi Nakamoto
June 25, 2010, 02:17:41 AM
I don't know. Maybe someone with more Linux experience knows how to
install the library it needs.
I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it
should have been built on an older version for more backward
compatibility. Is this a problem on Linux, that if you build on the
latest version, then it has trouble working on older versions? Is there
any way I can downgrade to an older version of GCC on 10.04?
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.
We don't need to bother with a 64-bit version for Windows. 32-bit
programs work on all versions of Windows. It's not like Linux where the
64-bit OS wants 64-bit programs.
I'm also curious if it's a little faster on linux than windows.
Do you think I should make the directories:
/bin32/
/bin64/
instead of
/bin/32/
/bin/64/
HostFat
June 25, 2010, 04:47:28 AM
Windows 7 x64
4 GB RAM
Intel i7 860
4 cores ( 8 virtuals ): 2200 khash/s
It's lower than Ubuntu :|
theymos
June 25, 2010, 07:18:54 AM
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.)
virtualcoin
June 25, 2010, 10:29:54 AM
Quote from: satoshi on June 25, 2010, 02:17:41 AM
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
Satoshi Nakamoto
June 25, 2010, 02:10:06 PM
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.
Satoshi Nakamoto
June 26, 2010, 12:32:09 AM
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)
NewLibertyStandard
June 26, 2010, 01:19:35 AM
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.
Satoshi Nakamoto
June 26, 2010, 03:10:10 PM
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.
Satoshi Nakamoto
June 26, 2010, 07:21:05 PM
Changed the version number to 1.3 and removed "Beta".
(links removed, see below)
Uses irc.lfnet.org.
laszlo
June 27, 2010, 02:45:28 PM
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.
Satoshi Nakamoto
June 27, 2010, 03:30:13 PM
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?
dkaparis
June 27, 2010, 10:02:25 PM
Quote from: satoshi on June 27, 2010, 03:30:13 PM
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?
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
Satoshi Nakamoto
July 02, 2010, 08:37:17 PM
Quote from: dkaparis on June 27, 2010, 10:02:25 PM
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.
Satoshi Nakamoto
July 02, 2010, 09:57:45 PM
(reverted to rc2)
Links removed, 0.3 is now released, so go to https://www.bitcoin.org to download
it.
laszlo
July 04, 2010, 07:39:32 PM
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
Satoshi Nakamoto
July 04, 2010, 09:52:28 PM
Laszlo's build is going to be our first Mac release so please test
it!
BitLex
July 06, 2010, 05:52:58 PM
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. 
Satoshi Nakamoto
July 06, 2010, 07:43:18 PM
0.3 released
https://bitcointalk.org/index.php?topic=238.msg2004#msg2004
Bitcoin 0.3 almost ready -- please test the Mac version!
2010 Jun 22 See all postsSatoshi Nakamoto
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
I finished everything on my list to do for version 0.3. The code on SVN is about ready to release.
Testing at this point is much appreciated.
I'm just here
Windows 7 x64
4 GB RAM
Intel i7 860
Very nice! There have definitely been some major improvements, including the hashmeter, RPC support, and a command-line daemon. It would be nice if the listtransactions RPC method were finished before the next release, though. Also, some code should be added to the JSON-RPC methods to list out dHashesPerSec.
Great work Satoshi!
Whoohoo! Can't wait!
Note, is there somewhere I can get a devel build?
Maybe we can setup nightly builds or something...
Should we try for some publicity? Slashdot is good if we can get it.
I've had a number of submissions accepted, though always by one editor that no longer works there. Anyone else with a Slashdot connection?
We should try to get publicity, and focus the campaign on the time right after the release to get the maximum impact: simultaneously advertising on forums, irc, Youtube, Facebook, Google Ads and other places. Slashdot with its millions of tech-savvy readers would be awesome, perhaps the best imaginable! I just hope the server can stand getting "slashdotted"
Maybe it should be upscaled beforehand just in case.
My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably.
We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do.
Here's RC1 for windows for testing:
(removed, see RC2 below)
Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in "c:files"
I just finished creating a clean Amazon EC2 debian 5.0 machine image with everything I needed to compile bitcoind, and it compiled (using a variation of Laszlo's makefile.unix) and is running fine (just finished downloading the block chain). I'll let you know if it misbehaves.
I had trouble compiling the gtk version, but I think that's because I did something wrong compiling wxWidgets. I don't need no stinkin' graphics (and am not a wxWidgets expert), so I'm not going to bother trying to fix that.
I have the same problem :|
What operating system?
Normally when it does that it's because the directory where the data directory should go doesn't exist. See if the "%appdata%" directory exists.
Do you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.
Windows 7 x64 ENG
4 GB RAM
Intel i7 860
I was using the v0.2.10 build by laszlo before yours.
davidonpda, were you also running laszlo's build previously?
Check if the "%appdata%" directory exists, and "%appdata%"
Try:
rename "%appdata%\bitcoin" bitcoin2does it work then?
Both are existing
Yes it works.
so I closed it, copied the walled.dat from the old folder to the new one, and now it's downloading blocks
Address book and old transfers seem ok, but there aren't anyone of old "generated coins" ... I just need to wait?
Anyway, I can just go back with the old v0.2.10
EDIT:
I did another thing.
Closed it, copied addr.dat / blk0001.dat / blkindex.dat from old folder to the new one.
Restarted bitcoin ( v0.30 ), and now it seems that everything is working. ( I can see also old generated coins now )
I just did NOT copied "log.0000000002" from the database folder ...
You figured it out faster than I could post a reply.
It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.
When you copied the directory except log.0000000002, that's the best solution. You should be good now.
The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don't go back to v0.2.10.
Anyone else who hits this problem, move the database.000000000* files somewhere else. (if it works fine after that, you can delete them later)
I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do.
yes, I'm just using 0.30 by now.
Thank you!
Runs fine under WINE. rhymes
It automatically switched the language to German, too. Now that I can see the translation in the client itself, I noticed a few things to improve, and will post a new .po file within the next two or so days.
Yeah, 0.3.0 seems to have a performance increase over svn r84 with Laszlo's performance patch.
Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.
30khash increase to what total rate? (to figure the % increase)
Much faster than Laszlo's build for me. Went from 600-700khash/s to 1000-1100khash/s on my Intel Core 2 Duo E8500. From 700-800khash/s on a laptop i7 to ~1100khash/s.
edit: Keeping the "Run Bitcoin" option checked in the installer seems to run it with admin privileges on the first launch. (in Win7)
Here's RC1 for linux for testing:
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the "-mt" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt.
Nice. :-)
64-bit version works fine on Ubuntu 10.04, of course it's (much) faster than through WINE emulation (and because it's 64-bit!?)
4 cores: 2850 khash/s
3 cores: 2130 khash/s
2 cores: 1420 khash/s
1 core: 700 khash/s
WINE (32-bit):
4 cores - 2300 khash/s
3 cores - 1740 khash/s
2 cores - 1150 khash/s
1 core - 580 khash/s
Thank you - looks pretty nice, too.
http://i50.tinypic.com/2ih1h0p.jpg
edit: What's the difference between "Sent/Received" and "All transactions"?
will it change something if you release a x64 bit version for Windows?
Ubuntu 9.04 x86:
Anybody know what Bitcoin needs?
I don't know. Maybe someone with more Linux experience knows how to install the library it needs.
I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?
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.
We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.
I'm also curious if it's a little faster on linux than windows.
Do you think I should make the directories:
/bin32//bin64/instead of
/bin/32//bin/64/Windows 7 x64
4 GB RAM
Intel i7 860
4 cores ( 8 virtuals ): 2200 khash/s
It's lower than Ubuntu :|
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.)
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
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.
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)
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.
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.
Changed the version number to 1.3 and removed "Beta".
(links removed, see below)
Uses irc.lfnet.org.
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.
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?
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
It is, but generating is more than twice as slow.
(reverted to rc2)
Links removed, 0.3 is now released, so go to https://www.bitcoin.org to download 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
Laszlo's build is going to be our first Mac release so please test it!
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.
0.3 released
https://bitcointalk.org/index.php?topic=238.msg2004#msg2004