etc

Author: strainer

drafts/late_ff_test.n

@@ -0,0 +1,40 @@
+comparing underscores memoizer to a case of 500 results, on firefox 2021
+
+Testing: warmup benchmarks 
+  Code: Math.sqrt(i)  ( squareroot ) 
+    136.7323 Kfunc/s   avg : 7455.619881760318 
+    154.4427 Kfunc/s   avg : 7455.619881755367 
+  Code: r+=i  ( fastest dummy test ) 
+    494.8802 Kfunc/s   avg : 125002.5 
+    374.3408 Kfunc/s   avg : 125002.5 
+  Avg op/s 290099.00691537646 
+mutil.js:282:13
+Testing: number, sin, mixed hit:500 
+  Code: r+=Math.sin(number[i])  ( Math.sin ) 
+    28.2365 Kfunc/s   avg : 3.920301118039033e-13
+    33.6509 Kfunc/s   avg : 3.92030111803885e-13 
+  Code: r+=ensin_0(number[i])  ( ensin_0 ) 
+    1.2053 Kfunc/s   avg : 3.92030111804194e-13
+    1.7656 Kfunc/s   avg : 3.92030111804194e-13
+  Code: r+=ensin__(number[i])  ( ensin__ ) 
+    1.5564 Kfunc/s   avg : 3.92030111804194e-13 
+    1.3629 Kfunc/s   avg : 3.92030111804194e-13 
+  Code: r+=ensin:500(number[i])  ( ensin:500 ) 
+    1.5821 Kfunc/s   avg : 3.92030111804194e-13 
+    1.0524 Kfunc/s   avg : 3.9203011180419395e-13
+  Avg op/s 8801.531209662862 
+
+Testing: number, multisin, mixed hit:500 
+  Code: r+=Multi.sin(number[i])  ( Multi.sin ) 
+    4.6483 Kfunc/s   avg : -76.39881759946037 
+    2.6075 Kfunc/s   avg : -76.39881759946057 
+  Code: r+=enmulti_0(number[i])  ( enmulti_0 ) 
+    872.2899  func/s   avg : -76.39881759946137
+    942.9967  func/s   avg : -76.39881759946131
+  Code: r+=enmulti__(number[i])  ( enmulti__ ) 
+    710.5950  func/s   avg : -76.3988175994616 
+    901.1175  func/s   avg : -76.39881759946137
+  Code: r+=enmulti:500(number[i])  ( enmulti:500 )
+    885.4073  func/s   avg : -76.39881759946148 
+    1.8303 Kfunc/s   avg : -76.39881759946084 
+  Avg op/s 1674.8084256709367

drafts/nosering.md

@@ -0,0 +1,53 @@
+Nose Ring Buffer - for quick collection of most frequent values.
+
+When there is a need to discover the most frequent values in a set, the instinct is to tally a frequency count for each value present and then sort the resulting set of value:tallie pairs - to get the most frequent values at the head of the sorted pairs, and least frequent at the tail.
+
+Building a set of value:tallie pairs and sorting it is not a featherlight process. A potentially lighter way to do this is to grow a list of values read out of the set, and sort this list while it is growing. This can be an O(n) process, the list of sorted values can be lighter to create than a list of value:tallie pairs.
+
+A 'Nose Ring Buffer' capable of this can be implemented with a single fixed array and a few pointers.
+It begins as a familiar cyclic ring buffer, and grows a 'nose' at its head where repeat values can be bubble sorted as they hit previous occurences in the array.
+
+function sniff(vals)
+{	
+	buff  = new Array(vals.length)
+	
+	ring_max = vals.length
+	ring_fills = 0
+	nose_max = Math.floor(ring_max/2)
+	last_in_ring = ring_max
+	nose_tip = 0
+	
+	top_tally = 0
+	
+  for( j=0 ; j<vals.length ; j++ ){
+    cv=vals[j]
+    
+    if(nrbuff[0]===cv){ top_tally++ }
+    else{
+      for(var i=1; i<nrbuff.length ; i++){
+        if(nrbuff[i]===cv) {
+        
+          if(i<=nose_tip){ dest = i-1 }else{ dest = nose_tip }
+          
+          if(i===1&&top_tally>1){
+	          top_tally--
+	        }else{
+            nrbuff[i] = nrbuff[dest] //evict an element down
+            nrbuff[dest] = cv        //swap hit element up
+          }  
+        }else{	  
+          //not found, so write to ring
+          if(last_in_ring === ring_fills) 
+          {  
+            if(ring_fills===ring_max){ 
+              last_in_ring = nose_tip 
+            }else{ 
+              ring_fills++ 
+            }
+          }   
+          nrbuff[++ringpin]=cv
+        }
+      }
+    }
+  }
+}

drafts/slate.n

@@ -0,0 +1,114 @@
+#fencache design notes
+------------
+* the key val storage option could perform better with equal buted inputs
+but is genrly hindered because arg/keys have to be stringified to be stowed 
+and checked.
+a recent value buffering stage could improve the store
+
+* the double ring buffer storage could turn itself off on long runs of misses
+and resume after a resting count
+or could reduce its search and not write...
+basically a gism to giveup on repeat misses, and forget the tail or whole queue.
+since excessive misses entail excessive time consumed.
+little extra time may need added to the general case
+in order to count and react to successive excessive misses.
+eg to 20 misses of 20 entries.
+but the optimisations could choke general performance on problem patterns
+however they may greatly smooth reaction to the more common problem pattern
+of frequent cache miss runs.
+
+gism 1
+after a number of long cache misses and writes,
+when rx gets to middle, split the cache and fill again
+as the low split of cache should be sorted infrequent anyway
+little point in keeping checking it
+gism 2
+when miss rx!==split point, count it and write res
+when miss rx==split point, and count high, and if count then refill again
+
+problem cache strat is different for slow 
+
+//----------------
+
+
+//----------
+
+# fencache
+
+Performance notes and data
+--------------------------
+
+Example benchmark scores:
+
+Test of worst case (all misses) with random unique inputs
+
+fencached perfomance:
+```
+Math.sin src performance, 30 Million func/s
+
+function  csize  speed % (of src) 
+enSin      1      60.0   
+enSin      2      50.0   
+enSin      3      15.0   
+enSin      4       6.0 
+ensin      50      0.8 
+ensin      200     0.2 
+```
+
+Test best case with 1 repeated input:
+```
+Math.sin,               30  Million func/s
+A multi.trig function,  1.7 Million func/s
+
+function  csize  speed % 
+enSin      1      220   
+enMTrig    1     3800 
+```
+ 
+Test on 90 normally distributed distinct values
+```
+Multi.trig function : 1.7 Mfunc/s
+
+function  csize  speed %
+enTrig      1      95
+enTrig      2      95
+enTrig      3      90
+enTrig     12     110
+enTrig     60     220
+enTrig    100     310
+enTrigx     0     840
+```
+
+Test a string processing functions on a selection of random length
+strings of upto 300 chars each, 200 of them repeated 4 times mixed up
+with 200 non repeated unique strings 
+```
+fast string process function : 130 Million func/s
+slow string process function : 5.9 Thousand func/s
+
+function  csize  speed %
+faststr     1      25.0   
+faststr     3       3.0    
+faststr    10       1.5
+faststr   100       0.3
+faststr   200       0.13
+faststr   400       0.2
+faststrx    0       8
+                
+slowstr     1     100    
+slowstr     3     100    
+slowstr    10     105
+slowstr   100     160
+slowstr   200     400
+slowstr   400    4600            
+slowstrx    0  190000 (%!)  
+```
+
+Writing memory can often be a comparatively heavy nano operation, even when we are just duplicating references. Since memoizing necessitates extra memory writes as well as lookups, memoizing calculation results 
+
+is only performant when there is
+some degree of repetition of parameters because keeping a larger cache size
+entails having more entries to check. Each cache search takes O(size) time
+for every miss. Fencache optimises lightly by floating results toward the head
+of the list each time they are recalled. This greatly suits unevenly distributed
+parameter sets and only marginally slows worst case.