kilic / fp Goto Github PK

There is a branch that demonstrates the issue.

Firstly, we have an assembly code that adds two 256 bit field element:

type Fe256 [4]uint64

// wrapper for field element interface
func Add4(c, a, b FieldElement) {
	add4(c.(*Fe256), a.(*Fe256), b.(*Fe256))
}
// declaration for asm code
add(c,a,b *Fe256)

And there is an interface for any field element:

type FieldElement interface {
  Marshal(out []byte) []byte
  Unmarshal(in []byte)
  // …
  // …
}

And there are two kinds of field implementation. First one is only for Fe256 type and the other one is for field element interface, so, the second one should support field elements with any bit size. First approach is at below:

type Field256 struct {
	pBig *big.Int
	r1   FieldElement
	r2   FieldElement
	P    FieldElement
}

func (f *Field256) Add(c, a, b FieldElement) {
	add4(c.(*Fe256), a.(*Fe256), b.(*Fe256))
}

In first implementation add4 decleration that runs the assembly code is called directly in the member method. Field initilizer below returns interface type.

func NewField(p []byte) Field {
// …
}

Here are rough benchmark results with add operation.

field1 := NewField(prime, a, b, c)
field2 := NewField(prime, a, b, c).(*Field256)
// 
// costs ~9 ns/op
field1.Add(a, b, c)
// ...
// costs ~5 ns/op, which is the target performance
field2.Add(c, a, b)

Now let’s take different approach and see the results of the general purpose Field implementation. As it can be seen below, we have now an add function as struct field. Given modulus this function should be set corresponding to bit size.

type FieldImpl struct {
	pBig *big.Int
	r1   FieldElement
	r2   FieldElement
	P    FieldElement
	add  func(c, a, b FieldElement)
}

func (f *FieldImpl) Add(c, a, b FieldElement) {
	f.add(c, a, b)
}

func NewField(p []byte) *FieldImpl {
	// …
	return  &FieldImpl{
		// …
		// ‘Add4’ function is a wrapper for ‘add4’ declaration
		add: Add4
	}
	
}

Well, again with another interface based approach benchmark results are not satisfying and addition operation costs around 9 ns/op.

My take is that, Using interfaces it is good for developer experienc and diminishing code size, switch case load. However, a when you don’t cast it to concrete type, using interface abstraction comes with a significant cost. Or there might be another way that comes with both and I missed.

So, when high performance is required, there should be æ seperate struct implementations for a group, extension tower or a pairing engines that uses these Fields, corresponding to their bit sizes. (For example, G1_256, G2_256, G2_320, G2_320 and so on.)