< bryyan>
if Bitcoin core is written in C++, why not support any kind of native interface directly (numbers as represented in memory going over tcp sockets as an RPC opposed to the serialised JSON RPC) ?
< gmaxwell>
because either it exposes internal datastructures which are unstable and change from version to version to outside applications; or it has to specify yet another encoding.
< gmaxwell>
and we do already have a binary encoding for most thigns: use the p2p protocol.
< bryyan>
I mean't like json but in a C struct
< bryyan>
and not a char* but between applications you would include a .h file containing the structs
< sipa>
structs don't have a well-defined serialization to bytes
< bryyan>
on the same architecture they do
< sipa>
different architectures store them differently in memory
< sipa>
just a different compilation option may change them
< bryyan>
yes, but why write bitcoin core in c++, a platform dependent language under many circumstances?
< bryyan>
additionally its often feasible to have multiple AMD64 machines which use the same format for C variables
< sipa>
efficiency, tight control over resource usage, high-level
< bryyan>
JSON is kind of cpu intensive to cast back and forth between native types you know
< bryyan>
directly copying 4 bytes of memory is far cheaper
< sipa>
you can use REST
< bryyan>
what is REST?
< sipa>
for some data with well-defined serialization, Bitcoin Core has a REST interface
< sipa>
you can fetch full blocks and transactions directly in binary network format over it
< bryyan>
without having to send a bunch of ascii json around?
< sipa>
to avoid the JSON encoding/decoding overhead
< sipa>
yes
< sipa>
but you still need a serialization/deserialization layer... it's not just a struct that gets sent over the network
< bryyan>
yes, but I'm looking for just that
< bryyan>
I assume I have 2 machines of identical architecture and the fastest means of transfering data is in native format
< sipa>
what's the native representation for a transaction?
< sipa>
it has a number of nested data structure of variable size
< gmaxwell>
none of the interesting data in bitcoin is just an int or a simple arrays of them.
< gmaxwell>
and as I said above, we do have a binary seralization of data: the p2p format.
< bryyan>
if you query for your balance, a float or double could work as a returned native type
< gmaxwell>
all ready for anyone to use.
< gmaxwell>
oh jesus bitcoin amounts aren't natively floating point.
< gmaxwell>
one should generally not use floating point when dealing with money.
< sipa>
bryyan: the cost of computing the balance is orders of magnitude larger than running a json deserializers
< bryyan>
you know, floating point has a certain number of digits of accuracy, just don't go too far
< bryyan>
I don't think we're talking about the same thing
< sipa>
fine
< bryyan>
in a native binary (such as bitcoind) certain instructions are applied to do math with integers and floating point types, the format of those values in memory are the native types
< bryyan>
pretty printed json is like 64 bytes to represent a 4-byte int
< bryyan>
very slow
< bryyan>
additional information is transfered over the network when keeping a header file with bitcoind and with the RPC client containing C macros which resolve to short 2-byte sequences for calls, and structs for reciving will take up far less thoroughput
< bryyan>
and after the word network there should be a comma I meant to put
< bryyan>
if you've written programs in C you would know what I'm talking about
< praxeology>
bryyan: how about create software and find the RPC api as a bottleneck before you look to optimize it
< bryyan>
for one thing, C doesn't handle JSON very well
< bryyan>
although thats more of a side problem
< phantomcircuit>
bryyan, the question you want to be asking yourself right now is
< phantomcircuit>
BUT WHY
< bryyan>
largely because I plan to make an operating system, and JSON puts in wayyy to much computational overhead compared to even a native-type conversion service
< bryyan>
you can convert endianness, format, and signing polarity far quicker then serialising and de-serialising some json
< gmaxwell>
Go away earlygrey.
< bryyan>
you could probably process 10s of requests in native format by the time a single JSON request completes
< bryyan>
maybe even 100s with a well-optimized binary
< luke-jr>
bryyan: jansson handles JSON good enough
< praxeology>
luke-jr: did you see he is making an operating system?
< bitcoin-git>
bitcoin/master 42307c4 Wladimir J. van der Laan: qt: Periodic translations update...
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10961: Improve readability of DecodeBase58Check(...) (master...DecodeBase58Check-cleanup) https://github.com/bitcoin/bitcoin/pull/10961
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10963: [bench] Restore format state of cout after printing with std::fixed/setprecision (master...restore-format-state-of-cout) https://github.com/bitcoin/bitcoin/pull/10963
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10964: Pass SendCoinsRecipient (208 bytes) and CConnman::Options (168 bytes) by reference (master...pass-big-parameters-by-reference) https://github.com/bitcoin/bitcoin/pull/10964
< BlueMatt>
#8330 could get a merge, tbh, its a free few-10s-of-k memory win
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10965: Use the noexcept specifier (C++11) instead of deprecated throw() (master...noexcept) https://github.com/bitcoin/bitcoin/pull/10965
< achow101>
whoever runs the doxygen site at dev.visucore.com needs to update their ssl cert. it expired this morning and I can't access it
< MarcoFalke>
wumpus: ^
< MarcoFalke>
It is issued by let's encrypt... I thought the point of that CA was that such updates are automatically done
< sipa>
MarcoFalke: they have automated the procedure for renewal to almost nothing, but there is stipl some script you need to run (potentially in a cronjob)
< sipa>
wumpus: ^
< bitcoin-git>
[bitcoin] promag opened pull request #10966: Add walletnotify functional test (master...2017-07-walletnotify-functional-test) https://github.com/bitcoin/bitcoin/pull/10966