freenode/#clasp - IRC Chatlog
Search
22:17:30
bjorkintosh
I should as claspy questions in clasp. so would it be possible then to create a uhh chemistry engine with an animated output to see how different chemicals react?
22:20:17
drmeister
bjorkintosh: There is a demo for visualizing a protein moving in the docker image - but it's broken at the moment but should be fixed in the next couple of days.
22:21:05
drmeister
And yes - it is possible to see the animated output of how different chemicals react.
22:23:34
drmeister
Here's one of a box of water with a protein in it. You can't see the protein well because it's blocked by all the waters.
22:32:07
drmeister
bjorkintosh: Biology happens in water - so you have to simulate water well. It turns out to be surprisingly difficult.
22:35:10
drmeister
Also, computers are really slow compared to how fast molecules move. It takes many minutes to hours to days to simulate a few nanoseconds. So we need fast machines and good algorithms.
22:36:40
drmeister
We have a range of modeling techniques, from modeling fundamental quantum mechanics (more accurate, terribly slow) to modeling molecules as balls connected by springs (less accurate and slow).
22:37:24
drmeister
Yes gpus help quite a lot. There's been a revolution in the last couple of years with the help of gpus. We can actually start to make good predictions of some molecular properties with the help of gpus.
22:39:43
drmeister
Setting up the calculations is very complicated and has to be done correctly or you get garbage.
22:40:10
drmeister
That's where we come in. I know how to write the code that sets up the calculation. That's what Cando is for.
22:42:21
drmeister
Then there are the more mundane problems like - you write something and how do you get it into their machines?
23:34:10
stassats
any self respecting gcd does that, but i guess with powers-of-two it can be simplified
23:50:38
drmeister
I found a bug in ComplexVectorCoordinates_O in cando that broke MPS. Cando is one step closer to working with MPS.
0:07:06
drmeister
I was calculating the size of ComplexVectorCoordinate_O wrong because of that stupid rank=1 thing.
0:08:28
drmeister
I should have a test mode where I allocate one of everything to make sure I'm calculating the sizes correctly.
3:35:38
beach
I remember you wanted to talk to me about something, but I don't remember what it was.
3:37:48
drmeister
I've been told that sbcl uses a scheme where the entry points for a call are calculated for each call. I was thinking of implementing something like that. Each call would involve looking up an address in a table for the function and calling that.
3:38:40
drmeister
Then I could index into the table depending on the number of arguments at the call site.
3:40:15
beach
He investigated call sites and found that most had 1, 2, or 3 arguments, so he specializes for those.
3:41:34
drmeister
Ok. I'm going to open up space in front of every function and write the table in there.
3:42:55
beach
I don't understand what that means, but I believe you. In SICL, a function is just a funcallable standard object, so I would just add a few more slots to it, one for each additional entry point.
4:05:04
beach
So, the idea is this: One slot in the function contains its static environment, and the first element of the static environment is the "code object" that contains various tables for GC and debugging. The entry points are just addresses so the GC does not look at those.
4:06:11
beach
Code doesn't move. It is managed by the global collector which uses the same technique as malloc/free on GNU/Linux (algorithm and data structure by Doug Lea).
4:08:05
beach
That vector is what is kept alive if any of the functions that share the same code object is live, or of the code object itself is live for some other reason.
4:13:30
beach
I also use the code object in ways that you don't. The debugger, when it displays source code, looks in the code object for a vector of strings with the characters of the entire source file in it. Then it displays that vector of strings in a CLIM window.
4:19:03
beach
It is unbelievable that we still use technology that was designed 50 years ago to be a stripped down version of something really good, so that it could run on a PDP-8.
4:19:57
beach
And it is unbelievable that our programming languages still try to make us think that we are programming the bare computer with all its memory available to us as a sequence of bytes.
4:23:53
beach
Oh, and apparently, most transistors in a modern processor, and most of the power it uses up, exist to make us think that we are still programming a PDP-11.