I might have a solution to the hashing overhead problem ... hashing the entire memory after the program has been executed (which is 256KB) is very bad. Why not instead keeping a "internal 128 bit state" which gets altered (using xor and rotation) with every operation the program performs. After the program executes, we only use the 12 integer input and the 128 state to calculate the pow hash? This would reduce the overhead to a minimum.
I think that could work. Once implemented, we just need to make sure that it doesn't penalize the work package execution time by any material amount.
Good point about the Int-Stream! Fixed that!
Works perfect ... we are back at over 40000 Evaluations per Second ...
Mostly of the slowdown comes from java itself. C implementations would be a LOT faster!
Per iteration of an ElasticPL program, we need only two hashes:
1x MD5 for personalized input integers
1x SHA256 for the POW hash itself
Both hash less than the 2*block size, so it it blazing fast! No more hashing of 256KB of data from the memory!
We should hard fork the change soon after thought about it for few more minutes.
Explanation: Every operation Mangles the result of that operation into a 128 bit long "garbage state" which is used for POW.
Nice side effect: Overhead increases with program complexity, and is no longer constant.
Example for the addition:
public void interpret()
{
jjtGetChild(0).interpret();
jjtGetChild(1).interpret();
top=top-1;
Integer int1 = 0;
Integer int2 = 0;
int1 = ((Integer)stack[top]);
int2 = ((Integer)stack[top+1]);
Integer result = int1+int2;
stack[top] = result;
mangle_state(result);
}
public static Long internal_state = 0L;
public static Long internal_state2 = 0L;
public static void mangle_state(int x){
if(x%2==0){
internal_state = Long.rotateLeft(internal_state,x%64);
internal_state = internal_state ^ x;
}else{
internal_state2 = Long.rotateRight(internal_state2,x%64);
internal_state2 = internal_state2 ^ x;
}
}
sorry 
