3 ms·

It takes your computer 323 milliseconds to convert an InChI key to a hash? You need to improve the implementation a bit there, I would expect a sha-256 operatio

by bdonlan 14y ago

It takes your computer 323 milliseconds to convert an InChI key to a hash? You need to improve the implementation a bit there, I would expect a sha-256 operation, even with a bit of string parsing first, to take _at most_ single digit milliseconds. Add to that a small EC2 cluster of multicore machines, and you should be able to do this in no time - no need for those fancy super-high-speed interconnects that the 'real' supercomputers have.

dalke 14y ago
I think I was too loose (read "wrong") in my nomenclature. I wrote "The IUPAC InChI keys are.." when I should have written "The IUPAC InChI strings are.." There's the long InChI string, and the shorter InChi key. The key is the hash form of the string. Generating the hash is, as you say, trivial given the InChI string. Computing the InChI string in the first place is not. It requires molecular perception of the input graph. For example, which of the hydrogen positions are mobile (eg, can be identical under tautomerization) and which are fixed? It also requires generating the canonical graph representation, which is done via a variation of the nauty algorithm. Usually it's quite fast. Some structures can take longer. By default there's a 60 second timeout. I haven't worked with the InChI code for a while, so I don't know what the performance numbers are. An output log from 2009 shows "Finished processing 2186 structures: 0 errors, processing time 0:00:05.93." or 369/second = 2.7ms. Perhaps its under 1.0 ms now? You estimated 323 milliseconds/record based on the numbers I gave. However, I did not describe the step which turns 977 million compounds into the actual number to evaluate. I would also include the combinations replacing Cl with F and with Br, and I would replace at most two of the nitrogens with a phosphorous. I may also have to try different hydrogen counts, depending on the types of structures in GDB-13. I guessed that this would require about 100x as much compute time as the base 977 million structures. This is all meant as very rough estimates. It's only been a background thought until now, and I hadn't written it up before. In any case, the parameters are all quite tunable, in that I could crank up or down the problem size to match the available CPU time and researcher patience.

by bdonlan 14y ago

dalke 14y ago

I think I was too loose (read "wrong") in my nomenclature. I wrote "The IUPAC InChI keys are.." when I should have written "The IUPAC InChI strings are.." There's the long InChI string, and the shorter InChi key. The key is the hash form of the string. Generating the hash is, as you say, trivial given the InChI string. Computing the InChI string in the first place is not. It requires molecular perception of the input graph. For example, which of the hydrogen positions are mobile (eg, can be identical under tautomerization) and which are fixed? It also requires generating the canonical graph representation, which is done via a variation of the nauty algorithm. Usually it's quite fast. Some structures can take longer. By default there's a 60 second timeout. I haven't worked with the InChI code for a while, so I don't know what the performance numbers are. An output log from 2009 shows "Finished processing 2186 structures: 0 errors, processing time 0:00:05.93." or 369/second = 2.7ms. Perhaps its under 1.0 ms now? You estimated 323 milliseconds/record based on the numbers I gave. However, I did not describe the step which turns 977 million compounds into the actual number to evaluate. I would also include the combinations replacing Cl with F and with Br, and I would replace at most two of the nitrogens with a phosphorous. I may also have to try different hydrogen counts, depending on the types of structures in GDB-13. I guessed that this would require about 100x as much compute time as the base 977 million structures. This is all meant as very rough estimates. It's only been a background thought until now, and I hadn't written it up before. In any case, the parameters are all quite tunable, in that I could crank up or down the problem size to match the available CPU time and researcher patience.