[RFC] Faiss Scalar Quantization FP16 (SQfp16)

Problem Statement
In k-NN plugin we mainly support vectors of type float where each dimension is 32 bits. This is getting expensive for use cases that requires ingestion on a large scale where we need to construct, load, save and search graphs(for native engines nmslib and faiss) which is getting even more costlier. Even though we have the byte vector support, it only supports lucene engine and also there is a considerable reduction in the recall when compared to float 32.
Adding support for Faiss SQFP16 helps to reduce the memory and storage footprints without compromising on recall where when user provides the 32 bit float vectors, the Faiss engine quantizes the vector into FP16 using their scalar quantizer (users don’t need to do any quantization on their end), stores it and decodes it back to FP32 while returning the results during search operations.
How Does the User Experience looks like ?
In terms of UX, users just need to set the encoder as SQfp16 while creating the index using faiss engine (this works only with faiss engine) and there is no change wrt ingestion and search queries. An example is shown below:
PUT test-index
{
  "settings": {
    "index": {
      "knn": true,
      "knn.algo_param.ef_search": 100
    }
  },
  "mappings": {
    "properties": {
        "my_vector1": {
          "type": "knn_vector",
          "dimension": 3,
          "method": {
            "name": "hnsw",
            "space_type": "l2",
            "engine": "faiss",
            "parameters": {
              "encoder": {
                 "name": "SQfp16"
              }
              "ef_construction": 128,
              "m": 24
            }
          }
        }
    }
  }
}

Benchmarking Results
Benchmarking on POC (In Progress)
Setup Configuration
Implemented a POC using the Faiss SQFp16 encoder and ran benchmarks against some of the datasets. The cluster configuration and index mapping are shown in below table.

Instance Type
r5.16xlarge

Nodes
1

Primary Shards
24, 8

Replicas
0

Disk Space
1000 GB

ef_search
256

ef_construction
256

m
16

engine
faiss

method
hnsw

Note - These results are without a warmup operation.
Recall and Storage Results

S. No.
Datasets
Dimension of Vector
Train Data Size
Query Data Size
Training Data Range
Query Data Range
Space Type
faiss-hnsw Recall
faiss sqfp16 Recall
faiss-hnsw Index Size
faiss sqfp16 Index Size
% reduction in storage

1
gist-960-euclidean
960
1,000,000
1,000
[ 0.0, 1.4772]
[ 0.0, 0.7285 ]
L2

2
sift-128-euclidean
128
1,000,000
10,000
[ 0.0, 218.0 ]
[ 0.0, 184.0 ]
L2
0.99989
0.99989
1.4 gb
1.1 gb
21.4 %

3
mnist-784-euclidean
784
60, 000
10,000
[ 0.0, 255.0 ]
[ 0.0, 255.0 ]
L2
1
1
400.2 mb
310.4 mb
22.43 %

4
fashion-mnist-784-euclidean
784
60, 000
10,000
[ 0.0, 255.0 ]
[ 0.0, 255.0 ]
L2
0.99999

447.6 mb

Indexing and Querying ResultsIndexing Throughput (docs/s) - The number of documents per second that can be ingestedDocument_Cnt / (total_index_time_s + total_refresh_time_s)Document_Cnt/ (( ingest_took_total)_s + (refresh_index_took_total)_s)Query Time (ms) -  Time per query, summarized as mean, p50, p90, p99

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
faiss hnsw - Indexing Throughput (docs/sec)
faiss sqfp16 - Indexing Throughput (docs/sec)
faiss hnsw Query time p50 (ms)
faiss sqfp16 Query time p50 (ms)
faiss hnsw Query time p90 (ms)
faiss sqfp16 Query time p90 (ms)
faiss hnsw Query time p99 (ms)
faiss sqfp16 Query time p99 (ms)

1
gist-960-euclidean
960
L2
24

2
sift-128-euclidean
128
L2
24
14837
1495
10
105.6
11
124.1
12.1
136

3
mnist-784-euclidean
784
L2
24
5657
545
9.8
204.7
10.2
226.2
12.9
240.2

4
mnist-784-euclidean
784
L2
8
5065
243
6
110
7
127.9
9.7
140.6

5
fashion-mnist-784-euclidean
784
L2
24
5175

8

9

11.7

Memory Results

S. No.
Datasets
Dimension of Vector
Space Type
faiss hnsw - Graph Memory Usage (MB)
faiss sqfp16 - Graph Memory Usage (MB)
% reduction in Native Memory

1
gist-960-euclidean
960
L2

2
sift-128-euclidean
128
L2
633.51367
389.37109
38.5 %

3
mnist-784-euclidean
784
L2
188.14258
98.42188
47.7 %

4
fashion-mnist-784-euclidean
784
L2
188.14258

Observations

Even after quantizing fp32 vectors to fp16 using Faiss Scalar Quantizer, we are able to get the same recall.
We are saving more than 21% in terms of storage.
In terms of memory, we are seeing a huge reduction ranging from 38% to 48% by using SQfp16 when compared to just the faiss with HNSW.
But, on the down side there is a huge drop in Indexing Throughput where using Faiss HNSW SQfp16 we are able to achieve only 1/10th of what we get with Faiss HNSW
Also, the Query Processing times looks very disappointing  where it takes 10 to 20 times more for SQfp16. But, reducing the number of primary shards from 24 to 8 helped to reduce the latencies a little but it still needs improvement.

Still working on ways to identify and reduce query latency and increase indexing throughput.
with Warmup and AVX2
These are the metrics after adding warmup operation and Faiss AVX2 support to k-NN.
Indexing and Querying Results

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
faiss hnsw avx2- Indexing Throughput (docs/sec)
faiss hnsw sqfp16 avx2- Indexing Throughput (docs/sec)
faiss hnsw avx2- Query time p50 (ms)
faiss hnsw sqfp16 avx2- Query time p50 (ms)
faiss hnsw avx2- Query time p90 (ms)
faiss hnsw sqfp16 avx2- Query time p90 (ms)
faiss hnsw avx2- Query time p99 (ms)
faiss hnsw sqfp16 avx2- Query time p99 (ms)

1
gist-960-euclidean
960
L2
24
1016
1059
26
25.6
29.3
28.9
32
31.1

2
sift-128-euclidean
128
L2
24
13178
13664
9.1
9
10.4
10
11.1
11

3
mnist-784-euclidean
784
L2
24
5711
5734
10
9
11
10
11.3
10.3

4
fashion-mnist-784-euclidean
784
L2
24
5325
5296
9
8
9.1
9
10.1
9.6

Observations (with AVX2)

Before enabling AVX2, ran few tests with warmup operation but we still don't see a good improvement in query latencies
With AVX2, we can see a significant improvement in the query latencies and indexing throughput for faiss hnsw with sqfp16 encoder by reducing the same memory and storage usage like we have seen in our previous test results. The new metrics are at par with faiss-hnsw results, some of the results are even better than that.
But, faiss hnsw with AVX2 didn't show much impact on the performance (not much improvement but no cons).
Also, with AVX2 we are able to achieve the same recall.

Benchmarking Results on ARM
As we have seen above, after adding the Faiss AVX2 optimization helped to improve the overall performance. But, AVX2 optimization only supports x86. As of now we don't have a similar optimization added for SQ in Faiss to support ARM. Ran few tests on ARM instances and shared the perf results below:
Recall and Storage Results

S. No.
Datasets
Dimension of Vector
Train Data Size
Query Data Size
Training Data Range
Query Data Range
Space Type
faiss-hnsw Recall
faiss sqfp16 Recall
faiss-hnsw Index Size
faiss sqfp16 Index Size
% reduction in storage

1
gist-960-euclidean
960
1,000,000
1,000
[ 0.0, 1.4772]
[ 0.0, 0.7285 ]
L2
0.99783
0.99831
16.6 gb
14.8 gb
10.84 %

2
sift-128-euclidean
128
1,000,000
10,000
[ 0.0, 218.0 ]
[ 0.0, 184.0 ]
L2
0.99989
0.99989
1.4 gb
1.1 gb
21.4 %

3
mnist-784-euclidean
784
60, 000
10,000
[ 0.0, 255.0 ]
[ 0.0, 255.0 ]
L2
1
1
400.3 mb
310.4 mb
22.43 %

4
last-fm
65
292,385
50,000

innerproduct
0.99897
0.99857
487.8 mb
451.5 mb
7.4 %

Indexing and Querying Results

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
faiss hnsw - Indexing Throughput (docs/sec)
faiss sqfp16 - Indexing Throughput (docs/sec)
faiss sqfp16 NEON - Indexing Throughput (docs/sec)
faiss hnsw - Query time p50 (ms)
faiss sqfp16 - Query time p50 (ms)
faiss sqfp16 NEON - Query time p50 (ms)
faiss hnsw - Query time p90 (ms)
faiss sqfp16 - Query time p90 (ms)
faiss sqfp16 NEON - Query time p90 (ms)
faiss hnsw - Query time p99 (ms)
faiss sqfp16 - Query time p99 (ms)
faiss sqfp16 NEON - Query time p99 (ms)

1
gist-960-euclidean
960
L2
24
983
952
997
22
73.2
34
24.1
84
38.1
25.6
88.2
40.1

2
sift-128-euclidean
128
L2
24
12869
6169
11126
8
18
10
8
20
11
9
21.9
11.1

3
sift-128-euclidean
128
L2
8
12182
4750
8992
4
10
5.4
4.9
11
6
5
12
7

4
mnist-784-euclidean
784
L2
24
4962
2910
4832
9
25
11
9.9
27
11.1
10.1
28
12.1

5
last-fm
65
innerproduct
24
9759

9845
6

6
6

6
6

7

6
last-fm
65
innerproduct
8
9515

9151
4

4
4

4
4

4

Memory Results

S. No.
Datasets
Dimension of Vector
Space Type
faiss hnsw - Graph Memory Usage (MB)
faiss sqfp16 - Graph Memory Usage (MB)
% reduction in Native Memory

1
gist-960-euclidean
960
L2
3807.34
1976.29
48 %

2
sift-128-euclidean
128
L2
633.51
389.37
38.5 %

3
mnist-784-euclidean
784
L2
188.14
98.42
47.7 %

4
last-fm
65
innerproduct
114.97
78.72
31.53 %

Observations

The recall is same with SQ.
The query latencies with SQ are a bit worse consuming 2 to 3.5 times more than what we see without SQ. But, far better when compared to those on x86 without AVX2 optimization.
The ingestion time is almost same. But, refresh and force merge are worse with SQ.
Like in x86, there is a significant drop in memory and storage utilization using SQ.
Adding SIMD optimization support using NEON for ARM helped to improve the query latencies and indexing throughput which are close to the corresponding metrics of faiss-hnsw without encoder (Except for large datasets like gist-960-euclidean, there is still a noticeable increase in query latencies).

Awesome to see recall is not noticeably impacted. This provides a lot of potential for cost reduction. A couple notes:
For consistency with product quantizer, I think it might make more sense for the interface to look like:
    "encoder":{
      "name":"sq",
      "parameters":{
        "nbits": 8
      }
    }

The performance implications are unfortunate. Im guessing they have to do with repeated conversion between fp16 and fp32. Might be worth investigating if it is possible to do flops directly on fp16 data (might be compiler/processor specific).

@naveentatikonda thanks for sharing the results. I can see good improvements on the Memory but the latency is big concern for me. 10X extra Search latency and 1/10th indexing throughput for 1M documents are big red flags for me.
Can we do these below things:

Work with Faiss maintainers to see why there is so much extra latency, may be some compiler optimizations may be missing.
Can we test with lets say a 10M dataset of 128 dimension and see does the latency follow the same trend?

Awesome to see recall is not noticeably impacted. This provides a lot of potential for cost reduction. A couple notes:
For consistency with product quantizer, I think it might make more sense for the interface to look like:
    "encoder":{
      "name":"sq",
      "parameters":{
        "nbits": 8
      }
    }

The performance implications are unfortunate. Im guessing they have to do with repeated conversion between fp16 and fp32. Might be worth investigating if it is possible to do flops directly on fp16 data (might be compiler/processor specific).

@jmazanec15 In terms of UX, we will add the parameters that are related to encoder, inside the encoder like in your example. But, the generic parameters like "ef_construction" related to hnsw will be outside the encoder object. Please correct me if I'm wrong.

@naveentatikonda thanks for sharing the results. I can see good improvements on the Memory but the latency is big concern for me. 10X extra Search latency and 1/10th indexing throughput for 1M documents are big red flags for me.
Can we do these below things:

Work with Faiss maintainers to see why there is so much extra latency, may be some compiler optimizations may be missing.
Can we test with lets say a 10M dataset of 128 dimension and see does the latency follow the same trend?

@navneet1v After enabling Faiss AVX2 feature, the query latencies and indexing throughput are improved. I have shared the results above. Please take a look.

hi, Is there any progress for this? we wanna introduce fp16 as a new codec. and we want to keep the protocol consistency with this.

hi, Is there any progress for this? we wanna introduce fp16 as a new codec. and we want to keep the protocol consistency with this.
@luyuncheng We have the AVX2 optimization support for x86 architecture. But, we don't have a similar optimization for ARM architecture to SQ in Faiss. So, we are working on adding NEON support to SQFP16 in faiss. We did a POC for L2 space type using NEON, which improved the overall performance and I'm working on adding the NEON support to InnerProduct.

Can you share more details about adding fp16 as a new codec ? Also, do you have the code ready ?

we do not test fp16 at ARM architecture. but we verify the fp16 at x86 architecture. so we want to introduce this into our services. also, i want to keep the protocol as same as you did, so it can backward in the future.
so i am wondering:

introduce a method name:"HNSWFP16"
or
introduce an parameter encoded like you do:

            "parameters": {
              "encoder": {
                 "name": "SQfp16"
              }
              "ef_construction": 128,
              "m": 24
            }

At #1139 i introduced a memory tests.  with sift128 1M dataset.

No @luyuncheng, can you pls explain how did you add fp16 support when you said that you will be adding it as a codec(in terms of implementation). Also,   based on the results that you have shared, the performance seems to have dropped in terms of query time and indexing time. Besides that, the memory also doesn't looks like it is optimized much when compared to the metrics obtained using AVX2 optimization support for x86 architecture. (results shared by me above)
We are planning to complete NEON optimization for ARM and release this feature in OpenSearch 2.12 (in Jan, 2024). So, even though we add SQfp16 support for x86, it is not going to be released now.

Besides that, the memory also doesn't looks like it is optimized much when compared to the metrics obtained using AVX2 optimization support for x86 architecture.

@naveentatikonda
i think the memory reduce size is almost same as your result shared above: 32%. (in query time).
Index performance i shared above do not using SIMD. i'll do a benchmark in avx2 with fp16 optimize.

@naveentatikonda
hi, I did more test with avx2 in Intel(R) Xeon(R) architecture, 8thread, 128 sift 1M dataset, i think HNSWSQfp16 is pretty good in time and memory

type
IndexTime
Build Index Memory
File Size
Query Index Memory
Query Time

HNSWSQfp16(avx2)
28305ms
1.535 GB
512 MB(-32%)
648 MB
4958 ms (-9.8%)

HNSWFLAT(avx2)
35543ms
1.772 GB
756 MB
892 MB
5498 ms

HNSWSQfp16
166505 ms
1.535 GB
512 MB(-32%)
647 MB
20578 ms(+54%)

HNSWFLAT
46688ms
1.768 GB
756 MB
891 MB
9012 ms

For consistency with product quantizer, I think it might make more sense for the interface to look like:

@jmazanec15 @naveentatikonda
SQfp16 do not need train data. is there any possible we can treat it as an hnsw encode parameters?

@luyuncheng I gave a thought on all your questions and tried to answer them here. Please take a look and let me know if you have any other questions.

Protocol and Index Mapping
In terms of protocol or index mapping, we will be accepting input from user as a new encoder like shown below and process the request. You can maintain the same consistency while using it in your services to avoid any backwards incompatibility.

            "parameters": {
              "encoder": {
                 "name": "SQfp16"
              }
              "ef_construction": 128,
              "m": 24
            }

Index Description or Implementation
SQfp16 do not need any training. In terms of implementation, we will be setting it as an encoder with index_description as HNSW16,SQfp16 (for HNSW) while passing the request to Faiss.

Release Timeline and ARM Support
Being the maintainers of k-NN repository, we cannot release partial features. So, we also want to add support for ARM architecture with optimization and release the complete SQfp16 feature (which includes both x86 and ARM support) in OpenSearch version 2.12.

cc: @vamshin @navneet1v @jmazanec15

@naveentatikonda
hi, I did more test with avx2 in Intel(R) Xeon(R) architecture, 8thread, 128 sift 1M dataset, i think HNSWSQfp16 is pretty good in time and memory
type	IndexTime	Build Index Memory	File Size	Query Index Memory	Query Time
HNSWSQfp16(avx2)	28305ms	1.535 GB	512 MB(-32%)	648 MB (-27%)	4958 ms (-9.8%)
HNSWFLAT(avx2)	35543ms	1.772 GB	756 MB	892 MB	5498 ms
HNSWSQfp16	166505 ms	1.535 GB	512 MB(-32%)	647 MB	20578 ms(+54%)
HNSWFLAT	46688ms	1.768 GB	756 MB	891 MB	9012 ms

@luyuncheng I'm curious to know how did you get these results. I mean did you run these tests directly on Faiss or through OpenSearch. Can you share more details ?

@naveentatikonda  Thanks for your reply!!

Protocol and Index Mapping
Index Description or Implementation

            "parameters": {
              "encoder": {
                 "name": "SQfp16"
              }
              "ef_construction": 128,
              "m": 24
            }

LGTM for the protocol, thanks!!

@naveentatikonda

I'm curious to know how did you get these results. I mean did you run these tests directly on Faiss or through OpenSearch.

i did it on OpenSearch.

Can you share more details

in #1139 , i added a memory tests, so it can easily using faiss_wrapper to create a new faiss index like opensearch jni did. when all native tests running ok with jni code, i added some parameter encode in the opensearch java code.

Updated the following results in Description of the issue:
Benchmarking Results on ARM
As we have seen above, after adding the Faiss AVX2 optimization helped to improve the overall performance. But, AVX2 optimization only supports x86. As of now we don't have a similar optimization added for SQ in Faiss to support ARM. Ran few tests on ARM instances and shared the perf results below:
Recall and Storage Results

S. No.
Datasets
Dimension of Vector
Train Data Size
Query Data Size
Training Data Range
Query Data Range
Space Type
faiss-hnsw Recall
faiss sqfp16 Recall
faiss-hnsw Index Size
faiss sqfp16 Index Size
% reduction in storage

1
gist-960-euclidean
960
1,000,000
1,000
[ 0.0, 1.4772]
[ 0.0, 0.7285 ]
L2
0.99783
0.99831
16.6 gb
14.8 gb
10.84 %

2
sift-128-euclidean
128
1,000,000
10,000
[ 0.0, 218.0 ]
[ 0.0, 184.0 ]
L2
0.99989
0.99989
1.4 gb
1.1 gb
21.4 %

3
mnist-784-euclidean
784
60, 000
10,000
[ 0.0, 255.0 ]
[ 0.0, 255.0 ]
L2
1
1
400.3 mb
310.4 mb
22.43 %

4
last-fm
65
292,385
50,000

innerproduct
0.99897
0.99857
487.8 mb
451.5 mb
7.4 %

Indexing and Querying Results

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
faiss hnsw - Indexing Throughput (docs/sec)
faiss sqfp16 - Indexing Throughput (docs/sec)
faiss sqfp16 NEON - Indexing Throughput (docs/sec)
faiss hnsw - Query time p50 (ms)
faiss sqfp16 - Query time p50 (ms)
faiss sqfp16 NEON - Query time p50 (ms)
faiss hnsw - Query time p90 (ms)
faiss sqfp16 - Query time p90 (ms)
faiss sqfp16 NEON - Query time p90 (ms)
faiss hnsw - Query time p99 (ms)
faiss sqfp16 - Query time p99 (ms)
faiss sqfp16 NEON - Query time p99 (ms)

1
gist-960-euclidean
960
L2
24
983
952
997
22
73.2
34
24.1
84
38.1
25.6
88.2
40.1

2
sift-128-euclidean
128
L2
24
12869
6169
11126
8
18
10
8
20
11
9
21.9
11.1

3
sift-128-euclidean
128
L2
8
12182
4750
8992
4
10
5.4
4.9
11
6
5
12
7

4
mnist-784-euclidean
784
L2
24
4962
2910
4832
9
25
11
9.9
27
11.1
10.1
28
12.1

5
last-fm
65
innerproduct
24
9759

9845
6

6
6

6
6

7

6
last-fm
65
innerproduct
8
9515

9151
4

4
4

4
4

4

Memory Results

S. No.
Datasets
Dimension of Vector
Space Type
faiss hnsw - Graph Memory Usage (MB)
faiss sqfp16 - Graph Memory Usage (MB)
% reduction in Native Memory

1
gist-960-euclidean
960
L2
3807.34
1976.29
48 %

2
sift-128-euclidean
128
L2
633.51
389.37
38.5 %

3
mnist-784-euclidean
784
L2
188.14
98.42
47.7 %

4
last-fm
65
innerproduct
114.97
78.72
31.53 %

Observations

The recall is same with SQ.
The query latencies with SQ are a bit worse consuming 2 to 3.5 times more than what we see without SQ. But, far better when compared to those on x86 without AVX2 optimization.
The ingestion time is almost same. But, refresh and force merge are worse with SQ.
Like in x86, there is a significant drop in memory and storage utilization using SQ.
Adding SIMD optimization support using NEON for ARM helped to improve the query latencies and indexing throughput which are close to the corresponding metrics of faiss-hnsw without encoder (Except for large datasets like gist-960-euclidean, there is still a noticeable increase in query latencies).

@naveentatikonda can we run the benchmarks with 1 shard. I see that all the experiments are done with 8,24 shards. Also, can you provide what was the number of shards for the results which you have posted.

@naveentatikonda can we run the benchmarks with 1 shard. I see that all the experiments are done with 8,24 shards. Also, can you provide what was the number of shards for the results which you have posted.

@navneet1v The test results that were posted above were ran with 24 shards and 8 shards (for some datasets) and 0 replicas. Now, I'm rerunning the benchmarking tests using 1 shard, 8 and 24 shards (to compare with the existing results) with the updated SQ changes in this PR https://github.com/facebookresearch/faiss/pull/3141

last-fm

With dimension 65, Im not sure the code path will be hit. Could you just run one sift with IP and see what the metrics diffs are?
Ref:

https://github.com/facebookresearch/faiss/blob/main/faiss/impl/ScalarQuantizer.cpp#L1164
https://github.com/facebookresearch/faiss/blob/main/faiss/impl/ScalarQuantizer.cpp#L1190

Also @naveentatikonda can you add in description tracking faiss issue? And then also the branch you are working on your changes with?

last-fm

With dimension 65, Im not sure the code path will be hit. Could you just run one sift with IP and see what the metrics diffs are?
Ref:

https://github.com/facebookresearch/faiss/blob/main/faiss/impl/ScalarQuantizer.cpp#L1164
https://github.com/facebookresearch/faiss/blob/main/faiss/impl/ScalarQuantizer.cpp#L1190

Good catch Jack. It won't hit the SIMD logic as it isn't a multiple of 8. Will run using some sift dataset to validate the query latencies.

Thanks @naveentatikonda . Seems like the new changes helped reduce the latency further.

This looks good to me. Lets go ahead and start trying to get this change into faiss! Nice work!

Created a draft PR to faiss repo. Pls take a look.
https://github.com/facebookresearch/faiss/pull/3166
cc: @vamshin @navneet1v @jmazanec15

Benchmarking results on x86 architecture with AVX2 using the new logic in SQ
These are the benchmarking results on x86 architecture with AVX2 using the new logic in SQ (with inline macros and other changes using SHUFFLE) included in this PR facebookresearch/faiss#3141
Recall and Storage Results
Note - We are seeing a drop in recall below for faiss-hnsw when compared with faiss-hnsw sqfp16 because the hyper parameter efConstruction used for sqfp16 is 512 whereas for faiss-hnsw the value was 256. Higher the value of efConstruction leads to more accurate graph and better recall.

As mentioned in the note, we have seen a drop in recall for faiss-hnsw due to the hyperparamter efConstruction. The updated recall values are listed below using the same default value (512). The below results also include the metrics comparison for cohere-wiki-simple-embeddings-768-l2 dataset.

S. No.
Datasets
Dimension of Vector
Primary Shards
Train Data Size
Query Data Size
Training Data Range
Query Data Range
Space Type
faiss-hnsw Recall
faiss-hnsw sqfp16 Recall
faiss-hnsw Index Size
faiss-hnsw sqfp16 Index Size
% reduction in storage

1
gist-960-euclidean
960
1
1,000,000
1,000
[ 0.0, 1.4772]
[ 0.0, 0.7285 ]
L2
0.95378
0.95368
16.6 gb
14.8 gb
10.84 %

2
gist-960-euclidean
960
24
1,000,000
1,000
[ 0.0, 1.4772]
[ 0.0, 0.7285 ]
L2
0.99863
0.99831
16.6 gb
14.8 gb
10.84 %

3
sift-128-euclidean
128
1
1,000,000
10,000
[ 0.0, 218.0 ]
[ 0.0, 184.0 ]
L2
0.9987
0.99867
1.4 gb
1.1 gb
21.4 %

4
sift-128-euclidean
128
24
1,000,000
10,000
[ 0.0, 218.0 ]
[ 0.0, 184.0 ]
L2
0.99989
0.99989
1.4 gb
1.1 gb
21.4 %

5
mnist-784-euclidean
784
1
60, 000
10,000
[ 0.0, 255.0 ]
[ 0.0, 255.0 ]
L2
0.99993
0.99993
400.1 mb
310.4 mb
22.43 %

6
mnist-784-euclidean
784
24
60, 000
10,000
[ 0.0, 255.0 ]
[ 0.0, 255.0 ]
L2
1
1
400.1 mb
310.4 mb
22.43 %

7
cohere-wiki-simple-embeddings-768
768
1
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
0.98625
0.98616
8 gb
7.4 gb
0.075 %

8
cohere-wiki-simple-embeddings-768
768
24
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
0.99641
0.99616
8 gb
7.4 gb
0.075 %

Indexing, Querying and Memory Results of Cohere Dataset

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
faiss hnsw avx2- Indexing Throughput (docs/sec)
faiss hnsw sqfp16 avx2- Indexing Throughput (docs/sec)
faiss hnsw avx2- Query time p50 (ms)
faiss hnsw sqfp16 avx2- Query time p50 (ms)
faiss hnsw avx2- Query time p90 (ms)
faiss hnsw sqfp16 avx2- Query time p90 (ms)
faiss hnsw avx2- Query time p99 (ms)
faiss hnsw sqfp16 avx2- Query time p99 (ms)

1
cohere-wiki-simple-embeddings-768
768
L2
1
782
792
33
33
34
34.4
35
35.8

2
cohere-wiki-simple-embeddings-768
768
L2
24
1175
1190
21
20
23
22
24.2
24

S. No.
Datasets
Dimension of Vector
Space Type
faiss hnsw - Graph Memory Usage (MB)
faiss-hnsw sqfp16 - Graph Memory Usage (MB)
% reduction in Native Memory

1
cohere-wiki-simple-embeddings-768
768
L2
1463.1992
766.1436
47.6 %

Benchmarking Results Comparison Between Faiss HNSW with AVX2 and Faiss HNSW SQFP16 with AVX2 for ms_marco-1m and cohere-768-1m-IP datsets
Recall Results

S. No.
Datasets
Dimension of Vector
Primary Shards
Train Data Size
Query Data Size
Training Data Range
Query Data Range
Space Type
faiss-hnsw Recall
faiss-hnsw sqfp16 Recall

1
ms_marco
384
1
1,000,000
50,000
[ -0.31676134, 0.31685343 ]
[ -0.2875412, 0.30342942 ]
L2
0.93597
0.93597

2
ms_marco
384
24
1,000,000
50,000
[ -0.31676134, 0.31685343 ]
[ -0.2875412, 0.30342942 ]
L2
0.98998
0.98979

3
cohere-768-IP
768
1
1,000,000
10,000
[ -4.1073565, 5.504557 ]
[ -4.109505, 5.4809895 ]
InnerProduct
0.76391
0.76324

4
cohere-768-IP
768
8
1,000,000
10,000
[ -4.1073565, 5.504557 ]
[ -4.109505, 5.4809895 ]
InnerProduct
0.94299
0.94214

5
cohere-768-IP
768
24
1,000,000
10,000
[ -4.1073565, 5.504557 ]
[ -4.109505, 5.4809895 ]
InnerProduct
0.97981
0.97863

Indexing and  Querying Results

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
faiss hnsw avx2- Indexing Throughput (docs/sec)
faiss hnsw sqfp16 avx2- Indexing Throughput (docs/sec)
faiss hnsw avx2- Query time p50 (ms)
faiss hnsw sqfp16 avx2- Query time p50 (ms)
faiss hnsw avx2- Query time p90 (ms)
faiss hnsw sqfp16 avx2- Query time p90 (ms)
faiss hnsw avx2- Query time p99 (ms)
faiss hnsw sqfp16 avx2- Query time p99 (ms)

1
ms_marco
384
L2
1
1571
1556
15
15
15
15
16.5
16

2
ms_marco
384
L2
24
2772
2618
7
7
7
8
10.5
8

3
cohere-768-IP
768
InnerProduct
1
844
850
28
28
28
29
30.5
30

4
cohere-768-IP
768
InnerProduct
8
1271
1294
8
8
10
10
12
12

5
cohere-768-IP
768
InnerProduct
24
1437
1446
10
9
11
11
12
12

Memory Results

S. No.
Datasets
Dimension of Vector
Space Type
faiss hnsw - Graph Memory Usage (MB)
faiss-hnsw sqfp16 - Graph Memory Usage (MB)
% reduction in Native Memory

1
ms_marco
384
L2
1610
877.65
45.5 %

2
cohere-768-IP
768
InnerProduct
3074.98
1610
47.64 %

@naveentatikonda those numbers look really good

Benchmarking Results Comparison Between Faiss IVF with AVX2 and Faiss IVF SQFP16 with AVX2 for cohere-wiki-simple-embeddings-768, ms_marco-1m and cohere-768-1m-IP datsets
Recall Results

S. No.
Datasets
Dimension of Vector
Primary Shards
Train Data Size
Query Data Size
Training Data Range
Query Data Range
Space Type
nlist
nprobes
faiss-ivf Recall
faiss-ivf sqfp16 Recall

1
cohere-wiki-simple-embeddings-768
768
1
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
4
2
0.93446
0.93847

2
cohere-wiki-simple-embeddings-768
768
1
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
128
4
0.77699
0.7956

3
cohere-wiki-simple-embeddings-768
768
1
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
128
8
0.88069
0.88745

4
cohere-wiki-simple-embeddings-768
768
1
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
512
8
0.81003
0.80722

5
cohere-wiki-simple-embeddings-768
768
8
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
128
8
0.88069
0.88745

6
cohere-wiki-simple-embeddings-768
768
24
475,858
10,000
[ -4.1561704, 5.5478516 ]
[ -4.065383, 5.4902344 ]
L2
4
2
0.93588
0.91818

7
ms_marco
384
1
1,000,000
50,000
[ -0.31676134, 0.31685343 ]
[ -0.2875412, 0.30342942 ]
L2
64
4
0.79061
0.77586

8
ms_marco
384
1
1,000,000
50,000
[ -0.31676134, 0.31685343 ]
[ -0.2875412, 0.30342942 ]
L2
128
4
0.74512
0.74619

9
ms_marco
384
1
1,000,000
50,000
[ -0.31676134, 0.31685343 ]
[ -0.2875412, 0.30342942 ]
L2
128
8
0.83593
0.83357

10
ms_marco
384
24
1,000,000
50,000
[ -0.31676134, 0.31685343 ]
[ -0.2875412, 0.30342942 ]
L2
128
8
0.83727
0.83758

11
cohere-768-IP
768
1
1,000,000
10,000
[ -4.1073565, 5.504557 ]
[ -4.109505, 5.4809895 ]
InnerProduct
128
8
0.79611
0.79028

12
cohere-768-IP
768
8
1,000,000
10,000
[ -4.1073565, 5.504557 ]
[ -4.109505, 5.4809895 ]
InnerProduct
128
8
0.78425
0.79671

13
cohere-768-IP
768
24
1,000,000
10,000
[ -4.1073565, 5.504557 ]
[ -4.109505, 5.4809895 ]
InnerProduct
128
8
0.80341
0.80161

Indexing and  Querying Results

S. No.
Datasets
Dimension of Vector
Space Type
Primary Shards
nlist
nprobes
faiss ivf avx2- Indexing Throughput (docs/sec)
faiss ivf sqfp16 avx2- Indexing Throughput (docs/sec)
faiss ivf avx2- Query time p50 (ms)
faiss ivf sqfp16 avx2- Query time p50 (ms)
faiss ivf avx2- Query time p90 (ms)
faiss ivf sqfp16 avx2- Query time p90 (ms)
faiss ivf avx2- Query time p99 (ms)
faiss ivf sqfp16 avx2- Query time p99 (ms)

1
cohere-wiki-simple-embeddings-768
768
L2
1
4
2
676
701
155.5
113
175.5
125
188.5
131.5

2
cohere-wiki-simple-embeddings-768
768
L2
1
128
4
692
494
42
36
50
40
54
43

3
cohere-wiki-simple-embeddings-768
768
L2
1
128
8
691
493
52
40
62
45
68.5
49

4
cohere-wiki-simple-embeddings-768
768
L2
1
512
8
684
514
40
33
46.5
37.5
51.5
39.5

5
cohere-wiki-simple-embeddings-768
768
L2
8
128
8
962
1081
13
10
16.5
12
19
14

6
cohere-wiki-simple-embeddings-768
768
L2
24
4
2
1031
1048
33.5
21
37
22.5
40
24

7
ms_marco
384
L2
1
64
4
1000
1042
30
23
35
25.5
39
28

8
ms_marco
384
L2
1
128
4
1014
1045
23
19
26
20
28
21

9
ms_marco
384
L2
1
128
8
1015
1041
29.5
22.5
33
25
36
26.5

10
ms_marco
384
L2
24
128
8
1981
2266
6
5
7
6
8
6

11
cohere-768-IP
768
InnerProduct
1
128
8
599
680
72
52.5
97.5
64.5
113.5
74.5

12
cohere-768-IP
768
InnerProduct
8
128
8
969
1096
19
13
25
16
29
19

13
cohere-768-IP
768
InnerProduct
24
128
8
1036
1182
16
11
23
14
26
17

Memory Results

S. No.
Datasets
Dimension of Vector
Space Type
faiss ivf - Graph Memory Usage (MB)
faiss-ivf sqfp16 - Graph Memory Usage (MB)
% reduction in Native Memory

1
cohere-wiki-simple-embeddings-768
768
L2
1408.02
710.96
49.51 %

1
ms_marco
384
L2
1492.27
759.85
49.08 %

2
cohere-768-IP
768
InnerProduct
2961.62
1496.77
49.46 %


Editor showing incorrect sprite resolution

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Windows 7 Professional , 64bit .
GeForce GTX 750ti
Godot 2.1.3  64 bit  (Windows)
Issue description:
I have a scene (I am using as a prefab) which has an Area2D root node.  This node has a Sprite and Collision2D under it.  The sprite shows one of several sprites from a sprite sheet with 32x32 sprites in it.
In the editor the sprites look sized correctly, and the scale on the Sprite shows 3x3. In the running game however the sprites are much too big.  I have attached screen shots to show what I mean.

In the top shot you can see the 9 prefabs (look like potions) and they are sized correct.  In the bottom image in game you see the image is much too large.
When I set the image on the prefab node, i set the region_rect and the modulate setting, and I don't touch the scale but its too large.  I even print the scale in game and its 3x3 so I know the editor is showing me one set of scale number but rendering another. (text output on the top image)
If I set the scale in my script to say 2x2 it looks the right scale but is off center because I centered it in the editor.

This is quite odd. Can you attach a minimal project that reproduces this bug?

Ok, at first I couldn't reproduce in a example project so I kept looking for differences.
I see what I was doing wrong now.  I had a scaling factor on the collision2D rectangle which I was using to line up the sprite in the editor.  But of course scaling on physics objects are dropped outside of the editor.  Once I made the scale 1 and re-positioned them everything is right.
Sorry for the false alarm, and thanks for listening!


Place menu 1px more to the side of the mouse cursor

On Linux.
If I open the editor context menu in a small enough window, the action right below the mouse cursor will be executed instantly, since the change that makes an action run on mouse up. We should nudge the menu 1px to the side (to the right when on the right side, to the left when on the left) in order not to have the menu right below the mouse cursor.
It doesn't repro if the window is large enough since the menu will be 1px nudged down in that case.

@joaomoreno sorry, I can't repro this on windows and I don't have access to my Linux VMs while traveling. Also, could you point me to where the nudging down happens so I can add left and right? I was looking in contextview.ts but didn't find it.

The nudging happens here: https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/contextmenu/contextmenu.ts#L99
This appears to be a bad place to do it, since it only affects editor context menus. I was able to fix my problem by adding 2 to the x coordinate, 1 was not enough. But other menus around the workbench still suffer from the same problem, e.g. explorer.

This seems to not be a problem on Windows where the menu does not seem to open on mouse down.

@sbatten PR up at https://github.com/Microsoft/vscode/pull/57614

Talking with @joaomoreno, needs support from the context view component.

Can confirm. If I right-click to open the context menu and the cursor ends up somewhere in the middle of the menu, the action under the cursor gets executed. I can avoid this if I keep the mouse button down, though.


[SPARK-8286] Rewrite UTF8String in Java and move it into unsafe package.

Unit test is still in Scala.

I will fix the imports now.

Merged build triggered.

Merged build started.

Test build #34579 has started for   PR 6738 at commit 2105c37.

Merged build triggered.

Merged build started.

Test build #34580 has started for   PR 6738 at commit b538bd6.

Test build #34579 has finished for   PR 6738 at commit 2105c37.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #34580 has finished for   PR 6738 at commit b538bd6.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #34639 has started for   PR 6738 at commit ea36cb3.

Test build #34639 has finished for   PR 6738 at commit ea36cb3.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #34644 has started for   PR 6738 at commit 4eff7bd.

Merged build triggered.

Merged build started.

Test build #34646 has started for   PR 6738 at commit 911c450.

Merged build triggered.

Merged build started.

Test build #34653 has started for   PR 6738 at commit 9a48e8d.

Test build #34644 has finished for   PR 6738 at commit 4eff7bd.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #34646 has finished for   PR 6738 at commit 911c450.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #34653 has finished for   PR 6738 at commit 9a48e8d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #34657 has started for   PR 6738 at commit 53f8ef4.

Test build #34657 has finished for   PR 6738 at commit 53f8ef4.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

@davies any idea why this test keeps failing on jenkins? i can't reproduce it locally.

For the UnsafeFixedWidthAggregationMap suite:
[info] - inserting large random keys *** FAILED *** (176 milliseconds)
[info]   461 was not equal to 512 (UnsafeFixedWidthAggregationMapSuite.scala:121)
[info]   org.scalatest.exceptions.TestFailedException:
[info]   at org.scalatest.MatchersHelper$.newTestFailedException(MatchersHelper.scala:160)
[info]   at org.scalatest.Matchers$ShouldMethodHelper$.shouldMatcher(Matchers.scala:6231)
[info]   at org.scalatest.Matchers$AnyShouldWrapper.should(Matchers.scala:6265)
[info]   at

Here's the source of that test:
 test("inserting large random keys") {
    val map = new UnsafeFixedWidthAggregationMap(
      emptyAggregationBuffer,
      aggBufferSchema,
      groupKeySchema,
      memoryManager,
      128, // initial capacity
      false // disable perf metrics
    )
    val rand = new Random(42)
    val groupKeys: Set[String] = Seq.fill(512)(rand.nextString(1024)).toSet
    groupKeys.foreach { keyString =>
      map.getAggregationBuffer(new GenericRow(Array[Any](UTF8String.fromString(keyString))))
    }
    val seenKeys: Set[String] = map.iterator().asScala.map { entry =>
      entry.key.getString(0)
    }.toSet
    seenKeys.size should be (groupKeys.size) <- this is the test that's failing
    seenKeys should be (groupKeys)
  }

Maybe we can add some print statements / logging to figure out what strings are being returned?  Based on the failure message, I wonder whether there's an issue with equals() or hashCode() but I can't seem to spot anything that's obviously wrong.  One culprit to watch out for would might be .equals() vs == in Java vs. Scala, but that's kind of a long shot I think.

Merged build triggered.

Merged build started.

Test build #34700 has started for   PR 6738 at commit 82d58cc.

Test build #34700 has finished for   PR 6738 at commit 82d58cc.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #896 has started for   PR 6738 at commit 82d58cc.

Jenkins, retest this please.

Merged build triggered.

Merged build started.

Test build #34711 has started for   PR 6738 at commit 82d58cc.

Merged build triggered.

Merged build started.

Test build #34714 has started for   PR 6738 at commit 1ff7c82.

Merged build triggered.

Merged build started.

Test build #34715 has started for   PR 6738 at commit a3b124d.

Test build #896 has finished for   PR 6738 at commit 82d58cc.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build triggered.

Merged build started.

Merged build triggered.

Merged build started.

Test build #34720 has started for   PR 6738 at commit 98e600b.

Test build #34720 has finished for   PR 6738 at commit 98e600b.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build finished. Test FAILed.

Test build #34711 has finished for   PR 6738 at commit 82d58cc.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #34721 has started for   PR 6738 at commit 562dc6e.

Test build #34714 has finished for   PR 6738 at commit 1ff7c82.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #34715 has finished for   PR 6738 at commit a3b124d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #34721 has finished for   PR 6738 at commit 562dc6e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.


Generalized array_position to get at most n element and start from certain position.

Is your feature request related to a problem or challenge?
While cleanup array_position I find we can extend it have better feature easily #7988
Background
array_position is the early function that follows on Postgresql.
There are three types of interface now.
array_position(array, element)
array_position(array, element, index)
array_positions(array, element)

array_position(array, element)  is the basic one.

For example array_position([1,2,3], 3) return 3 (1-indexed).

array_position(array, element, index)  finds the element start_from index.

For example array_position([1,2,3,4,3], 3, 4)  return 5.

array_positions(array, element) return all the occurrence of the elements.

For example array_positions([1,2,2,3,3,3], 2) return [2,3].

Problem
We are not able to find n element start from certain index.
Proposal 1 Extend the current interface
array_position(array, element, Option<index>, Option<n>) that able us to find n elements start from index and
array_positions(array, element, Option<index>) that able us to find all the elements start from index.
Proposal 2 Introduce array_position_n
array_position(array, element, Option<index>) that able us to find 1 element start from index.
array_position_n(array, element, n, Option<index>) that able us to find n elements start from index.
array_positions(array, element, Option<index>) that able us to find all the elements start from index.
I think either of two are good for me, so I would like to collect feedbacks from yours.
Others than PostgreSQL
Duckdb
list_position(list, element) has only the basic one.
Clickhouse
None
Spark
array_position(column: Column, value: Any)  has only the basic one.
Azure
array_position(array, element) has only the basic one.
Note
I had not yet find other SQL have the similar function, so I'm not sure if this feature is helpful or not.
Describe the solution you'd like
Extend array_position
Describe alternatives you've considered
Keep it as it is.
Additional context
No response

FWIW this likely can just be implemented by slicing the list values and creating a new set of offsets

I had not yet find other SQL have the similar function, so I'm not sure if this feature is helpful or not.

I recommend we don't implement this ahead of someone actually asking for it / having a concrete usecase. "if it is good enough for spark / DuckDB it is probably good enough for DataFuaion"


Performance and Prospects: MLIR-Generated CUDA vs CUTLASS/TensorRT?

Hi team,
I formulated the question while reviewing the latest advancements in OpenAI's Triton, particularly the transition to using MLIR for replacing LLVM PTX and adding support for Nvidia Hopper. I'm curious about your opinions regarding the decision of choosing MLIR over other CUDA libraries, e.g. CUTLASS/TensorRT, instead of handwritten CUDA kernels.
I'm interested in understanding the performance implications of MLIR-generated CUDA code compared to alternatives like CUTLASS, TensorRT, or even solutions such as TVM's custom CUDA code generation. From what I've gathered, preliminary results from projects like AITemplate highlight CUTLASS as exceptionally efficient. Additionally, there's the well-established TensorRT, which has historically been a top-performing option in the CUDA ecosystem.
Given my lack of familiarity with MLIR and the CUDA code it's capable of producing, I'm curious about the motivation behind the decision to rewrite with MLIR. In the pull request for the rewrite, @ptillet mentioned the potential for "ultimate performance" with MLIR. Does this suggest that MLIR-generated CUDA code could potentially surpass CUTLASS and TensorRT in specific workloads? It would be incredibly helpful if you could provide some context and delve into this topic further. Thank you in advance for your insights!

Does this suggest that MLIR-generated CUDA code could potentially surpass CUTLASS and TensorRT in specific workloads

Yes, at least if the frontend is Triton

@Jokeren Thanks for the reply! Does that mean you guys tried different cuda codegen path for triton, like MLIR/CUTLASS/TensorRT and CUDA kernels generated by MLIR yield the best result? Would that be possible that some insights on this can be shared, e.g. what workload are tests, what is the different between generated cuda code that lead to the perf gap and what the perf number look like? Would really appreciate that!

@shingjan did you find an answer to your question and/or data affirmatively supporting @Jokeren statement ?
if so, would be great if you can share.

MLIR is just a tool, with enough efforts whether you're using Cutlass or anything else does not matter: all of these end up generating NVVM/PTX.
The question is about the effort you need to put to get the right PTX generated for all the use-case you care about.
Cutlass has very strong foundation to scale the generation of kernels across a wide range of needs, and this provides an excellent reference.
However while this is a great library, the needs of a compiler powering a DSL like Triton are a bit different, and Cutlass isn't necessarily always the most practical option to build such a compiler. MLIR provides on the other an excellent foundation for building such a tool, and you can then take inspiration of the Cutlass recipes as a blueprint to build your MLIR compiler.

Indeed, yet Effort * Experience is not free. And I can't agree more on "take inspiration of the Cutlass recipes as a blueprint to build your MLIR compiler".  So.. the proof is in the pudding (i) What inspiration MLIR takes from CUTLASS ? (ii) is there any intersting MLP dimensions benchmark showing relative performance  -  say Ampere where both are are stable  (iii) BTW, Is there any compare and contrast between Triton IR approach and Graphene IR which does seem to take some inspiration (at least) from cuTe?
Nvidia’s Graphene IR approach
https://www.youtube.com/watch?v=wtpxe5RREjQ
And the paper.
https://dl.acm.org/doi/pdf/10.1145/3582016.3582018


Loss functions module

In this PR, I suggest a new module for loss functions. The module is very simple and is actually only an intermediary between ClinicaDL and PyTorch's nn module. More precisely, there is:

a LossConfig class, with all the parameters useful for PyTorch's loss functions,
a factory function get_loss_function that will get a PyTorch loss function and parametrize it thanks to a LossConfig object. This function also returns a config dict with only the parameters relevant to the wanted loss function (whereas a LossFunction object contains the parameters for all loss functions available), because one only wants to save the information related to the wanted loss function in the MAPS.

Update: I added an option "DefaultFromFactory" in the config class to use by the default the default values from PyTorch's loss functions, instead of manually copy/paste the defaults in our config class.


fix(scripts): skip failure report for ruby

🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/DI-2494
Changes included:
le ruby release succeed but the ruby release action then lookup on the registry to find the version and somehow fails (but it worked!)
since the GA release approach and we need wait release to succeed in order to spread new versions to the docs, we can skip ruby for now

🤝 nice


Currently Todo panel is too long

@tmciver The currently doing panel is the same size of the other panels. It should only contain a small amount of todos so its height should be relatively smaller compared to the other panels.  Let me know if this opinion is shared?

I'm not sure about that - I guess I'd have to see what it looks like.  My feeling is that it might look strange if the last column is short when the others are the full viewport height.  Try it out and we can see what it looks like.

@demamoh interestingly the "Currently Doing" panel is not the same size as the other panels: it's a bit longer and when I looked into it it appears to be some CSS coming from the Bulma CSS file imported here.  Did you add this or was it part of the template?  It turns out that divs with class panel are treated specially and panels that are not the last child are styled a bit differently than the last child.  Should be easy enough to fix.


rename:[UIUX-441] updated the plugin subtext

Description
Updated the subtext under plugin name in add-plugin screen.

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List
any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Chore (no code changes)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also
list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] My commit message/PR follows the contribution guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Other information:
List any documentation updates that are needed for the Wiki

closing this as we are not adding other plugins here


Soft delete a project

for the time being we will soft delete projects, later we might do some automatic cleanup of these projects but this is what can do for now. The repo will be moved into a sub folder, users will be removed from the project and a deletedAt column will be set with the date (null by default), we should then filter out deleted projects from the admin view

[ ] deletedAt column, null by default
[ ] move repo into sub folder for deleted projects
[ ] hide from admin view
[ ] remove all project users from deleted project
[ ] enable showing deleted projects in admin view

FYI I created an API for deleting projects permanently, however it will only allow you to delete projects that have the Dev retention policy. Do not use this endpoint in the ProjectController to implement soft delete.

Tested this out by deleting a project and it worked fine.


Propose a new assertThat(ThrowingCallable) signature with hasNotThrownException() assertion

The signature can be used to verify that call don't raise an exception, instead of relying on other technics. This allows to have a finer control over statement(s) that should or should not raise an exception.
The idea of this API is to be able to write assertions like that :
assertThat(() -> foo.bar()).hasNotThrownException();
assertThat(() -> jedi.saber()).hasNotThrownException();

Ideas on how to improve this PR are welcome ; API signature, name alternative, documentation, ...

I have a slight preference for didNotThrowAnyException but your wording works ok too, I'm fine keeping it if you feel strongly about it, ex:
assertThat(() -> jedi.saber()).didNotThrowAnyException();

Improvements :

add javadoc to hasNotThrownException or didNotThrowAnyException, we try to have some useful javadoc for every user facing methods (greatly inspired by ... Mockito, just saying  :wink:).
hasNotThrownException should also display the thrown exception in the error message, that will help understand what went wrong.

Build failing (AssertionsTest), whenever an assertThat method is added to Assertions, it checks that:

the same method exists in AbstractStandardSoftAssertions and WithAssertion
the corresponding then method exists in BDDAssertions.

I have rebased this PR and fixed the tests and improved the javadoc but I'm facing a usability problem, the following code from your original javadoc won't compile:
assertThat(() -> { throw new Exception("boom!"); }).didNotThrowAnyException();

the compiler reports the following error (a bit reformatted):
reference to assertThat is ambiguous both method
  <T>assertThat(T) in org.assertj.core.api.Assertions
and method
  <ELEMENT>assertThat(java.lang.Iterable<? extends ELEMENT>) in org.assertj.core.api.Assertions
match
incompatible types: cannot infer type-variable(s) T
(argument mismatch; T is not a functional interface)

To fix that, one needs to extract the lambda to a local variable that will fix the type inference ambiguity, this is possible but not great from a usability point of view (I already imagine users complaining about that ...)
I'm not sure there is a way to disambiguate the initial code, anyway I'd like to have your thoughts about this.

Didn't see your comment, yesterday I was pushing in a hurry yesterday while on the go ;)
I'm still  exploring the idea though, the compilation issue of the javadoc seems to be a real issue though. I'd look into it.

not great from a usability point of view (I already imagine users complaining about that ...)

Indeed I agree. The ambiguity didn't exist before because the API was named differently. That could be the option here.

I'll see if I can find a good name, I have the feeling that if we don't use assertThat it's not gonna be easy to discover.
PS : I haven't pushed the rebased commits on any branch

First, I'm gonna use the present tense instead of the past so replacing didNotThrowAnyException by doesNotThrowAnyException since AssertJ uses the present tense.
Second, at the moment I thinking of renaming assertThat(ThrowingCallable tc) to

assertThatCode(ThrowingCallable tc)
assertThatThrowingCallable(ThrowingCallable tc)

assertThatCode(() -> { throw new Exception("boom!"); }).doesNotThrowAnyException();
assertThatThrowingCallable(() -> { throw new Exception("boom!"); }).doesNotThrowAnyException();

I kinda prefer assertThatCode I must say, any ideas welcome.

I kinda like asserThatCode, other alternatives : assertThatBlock ?
Do you think we can add an @Incubating annotation, to indicate possible renaming ?

Let's go for assertThatCode, good idea to use an incubating annotation.

OK, let's go for assertThatCode :)

done.


String descriptors can panic on to_string

If you have a descriptor with String keys, and you parse one with a key outside of the checksum alphabet, desc_checksum will fail, leading to returning an error from Display::fmt, which apparently causes a panic in .to_string().
I'm not sure why we haven't seen this before but when fuzzing locally it now shows up quickly on the roundtrip_descriptor fuzztest. For example you can give it the test vector
do_test("pkh(\u{16})".as_bytes());

I'm unsure what the best plan of action here ... String descriptors aren't standardized, so I guess we can just make something up. The two ideas that come to mind are:

Enforce, when parsing descriptors, that every character lands in the checksum alphabet (or at least, is ASCII-printable, which I think might be the same thing)
When computing checksums, skip invalid characters or replace them with x or something
Keep the existing behavior (though then we'd need to tweak our fuzztests somehow)

Also affects elements-miniscript.

Hey @apoelstra Do we need escape characters (or in general non printable ASCII characters) in a descriptor string strictly for fuzztests or in any other parts? If not then I would love to go ahead for 1st way. If it is required then the 2nd and finally to avoid changing fuzztests.

No, escape characters are not required in any contexts that I'm aware of. I don't think we have tests for such characters and if we did, it would be fine to drop them if we were to forbid the behavior.

Ah, I see this being already solved with https://github.com/rust-bitcoin/rust-miniscript/commit/6b76997b14fd606b6ceba884012512c06200a4a4


Update Behemoth icons

Summary
I have noticed that the app icons have different dimensions, their size could be optimized a bit more and the Phaelanx icon does not match the same style as the rest, so I have decided to update the Behemoth icons to fix these issues.
Details

Icons have different dimensions.
The icon size could be optimized a bit more.
The Phaelanx icon does not match the same style as the rest.

Suggestions
Throughout the game, slayers face different Behemoths from the same family, for example, the Boreus family:

Lesser Boreus
Boreus
Dreadfrost Boreus
Lightbound Boreus

The type of Boreus that appears on Lady Luck Island is the Dreadfrost Boreus, so I recommend renaming the Behemoth icons, correctly adjusting the name that corresponds to each icon. To facilitate this task, I attach a table with the changes to be made:

Current name
Updated name

Blaze Quillshot
Flameborn Quillshot

Boreus
Dreadfrost Boreus

Charrogg
Firebrand Charrogg

Embermane
Bloodfire Embermane

Gnasher
Ragetail Gnasher

Kharabak
Razorwing Kharabak

Nayzaga
Shockjaw Nayzaga

Pangar
Frostback Pangar

Quillshot
Deadeye Quillshot

Shrike
Moonreaver Shrike

Skarn
Rockfall Skarn

Skraev
Winterhorn Skraev

Stormclaw
Tempestborne Stormclaw

I have not decided to add these changes directly in this pull request since I consider that it is not a change that must be made no matter what, it is simply a suggestion.

@FJrodafo
First of all many thanks for taking your time to navigate in this project :)
Thanks for the image adjustment
Created #2 for the naming part


README example should include "import" lines

The examples in the README are good, but none of them show the required import lines that are needed to define the decorators:
import 'reflect-metadata' // optional, if you're using it
import { jsonObject, jsonMember, jsonArrayMember, jsonMapMember } from 'typedjson'

Would be nice if the examples included those for newbies.

Hey Garyo, I've added imports to the examples. Do you think it is better now?


[proxy] Handle null HostConfigs gracefully in start

Fixes #1481

@paulbellamy Please review

Could you just remove the & on the unmarshal call? would that be simpler?

Also, what's the -o /dev/null -w "%{http_code}\n" to curl?

Also, does curl fail on response codes >= 400?

Could you just remove the & on the unmarshal call? would that be simpler?

Yep, that would be simpler, good point.

Also, what's the -o /dev/null -w "%{http_code}\n" to curl?

It prints the status code of the curl request

@paulbellamy @rade PTAL


monitoring->graphs no data，Pls help on this

Monitoring->Latest data
Data collector

07/04/2019 01:13:56 PM
History opcounters1562217175 13 68 25 4499 83007 317240{"failed": 17, "chunk": 1, "total": 17, "processed": 0, "time": "0.000294"}

07/04/2019 01:12:56 PM
[Errno 2] No such file or directory: '/tmp/<IP_ADDRESS>-opcounters'History opcounters1 0 0 0 0 0 0{"failed": 17, "chunk": 1, "total": 17, "processed": 0, "time": "0.000378"}

mongostat --host <IP_ADDRESS>:9927 -u root -p123456 --authenticationDatabase admin --rowcount 1
insert query update delete getmore command dirty used flushes vsize  res qrw arw net_in net_out conn  set repl                time
*0    *0     *0     *0       0    12|0  0.4% 0.4%       0 1.31G 103M 0|0 1|0  1.40k   70.9k    9 myrs  PRI Jul  4 14:02:38.442
*Zabbix 4.2、mongodb 4.0.9

just rm all the files like /tmp/<IP_ADDRESS>-opcounters manually. the script runs under zabbix server user and can't open the file in /tmp directory if you tried to run the script manually under your shell access
.

Thank you for your reply
[root@centos tmp]# rm <IP_ADDRESS>-opcounters
rm: remove regular file '<IP_ADDRESS>-opcounters'? y
Monitoring->Latest data->Data collector

07/04/2019 02:22:56 PM
History opcounters1562221316 13 138 25 4555 84338 329194{"failed": 17, "chunk": 1, "total": 17, "processed": 0, "time": "0.000508"}

07/04/2019 02:21:56 PM
[Errno 2] No such file or directory: '/tmp/<IP_ADDRESS>-opcounters'History opcounters1 0 0 0 0 0 0{"failed": 17, "chunk": 1, "total": 17, "processed": 0, "time": "0.000463"}

monitoring->graphs no data

Please check that {$MONGODB_ZABBIX_NAME}  is properly set.
Like this

I did not fill in correctly before, but I have corrected it now.

[root @ centos tmp] #systemctl restart zabbix-server zabbix-agent httpd

Timestamp
Value

07/04/2019 03:30:56 PM
History opcounters1562225395 13 203 25 4568 85659 337415{"failed": 17, "chunk": 1, "total": 17, "processed": 0, "time": "0.000314"}

monitoring->graphs no data

It looks like there something wrong with data packet for zabbbix...
pls append the line
print(packet)
at the end of mongod-db.py and send me Data collector lines

Timestamp
Value

07/04/2019 04:51:56 PM
History opcounters1562230256 13 289 27 4586 87252 347278{"failed": 17, "chunk": 1, "total": 17, "processed": 0, "time": "0.000411"}[{"host": "consul1 ", "value": "1", "key": "mongodb_state"}, {"host": "consul1 ", "value": "OK", "key": "mongodb_errstr"}, {"host": "consul1 ", "value": "8", "key": "mongodb_conn"}, {"host": "consul1 ", "value": "myrs", "key": "mongodb_rs_name"}, {"host": "consul1 ", "value": "PRI", "key": "mongodb_rs_status"}, {"host": "consul1 ", "value": "1", "key": "mongodb_aclients_read"}, {"host": "consul1 ", "value": "0", "key": "mongodb_aclients_write"}, {"host": "consul1 ", "value": "1", "key": "mongodb_vsize"}, {"host": "consul1 ", "value": "0", "key": "mongodb_netin"}, {"host": "consul1 ", "value": "0", "key": "mongodb_netout"}, {"host": "consul1 ", "value": "0", "key": "mongodb_insert"}, {"host": "consul1 ", "value": "0", "key": "mongodb_update"}, {"host": "consul1 ", "value": "0", "key": "mongodb_delete"}, {"host": "consul1 ", "value": "0", "key": "mongodb_query"}, {"host": "consul1 ", "value": "20", "key": "mongodb_getmore"}, {"host": "consul1 ", "value": "120", "key": "mongodb_command"}, {"host": "consul1 ", "value": "140", "key": "mongodb_total_ops"}]

It is strange, I have very similar line on my servers
[{"host": "mongo1", "value": "1", "key": "mongodb_state"}, {"host": "mongo1", "value": "OK", "key": "mongodb_errstr"}, {"host": "mongo1", "value": "160", "key": "mongodb_conn"}, {"host": "mongo1", "value": "rs-raw1", "key": "mongodb_rs_name"}, {"host": "mongo1", "value": "PRI", "key": "mongodb_rs_status"}, {"host": "mongo1", "value": "21", "key": "mongodb_vsize"}, {"host": "mongo1", "value": "0", "key": "mongodb_netin"}, {"host": "mongo1", "value": "0", "key": "mongodb_netout"}, {"host": "mongo1", "value": "8751", "key": "mongodb_insert"}, {"host": "mongo1", "value": "11327", "key": "mongodb_update"}, {"host": "mongo1", "value": "6", "key": "mongodb_delete"}, {"host": "mongo1", "value": "177", "key": "mongodb_query"}, {"host": "mongo1", "value": "3407", "key": "mongodb_getmore"}, {"host": "mongo1", "value": "4815", "key": "mongodb_command"}, {"host": "mongo1", "value": "28784", "key": "mongodb_total_ops"}]
Pls check the zabbix-server log file for errors

Zabbix4.2->Zabbix4.0
zs.py

[root@centos externalscripts]# ./zs.py
{"failed": 0, "chunk": 1, "total": 2, "processed": 2, "time": "0.000161"}
[{"host": "consul1", "value": "100", "key": "mongodb_conn"}, {"host": "consul1", "value": "1", "key": "mongodb_query"}]
It's strange. In theory, the effect should be the same.，but mongod-db.py -> {"failed": 16, "chunk": 1, "total": 16, "processed": 0, "time": "0.000326"}

Macros->{$MONGODB_ZABBIX_NAME}
The value of a variable does not contain spaces, but there is one more space at the end of the value of the variable when it is obtained.
print("[muser:"+muser+",mpass:"+mpass+",mongohost:"+mongohost+",mongoport:"+mongoport+",zbhost:"+zbhost+"]")
[muser:root,mpass:root,mongohost:<IP_ADDRESS>,mongoport:9927,zbhost:consul1 ]

Thank you!


Don't use localName to identify tags, if it's not populated

Don't use localName to identify tags, if it's not populated.
In browsers that don't populate localName, idom couldn't identify the tag name during patch, and would always think that a different tag was being re-rendered, always recreating DOM nodes rather than reusing them (you can't change the tag name of an existing node).
I verified this issue on Cobalt 9, but this may also affect IE <=8 and other old browsers. https://caniuse.com/?search=localName
Quick links:

Element.localName https://developer.mozilla.org/en-US/docs/Web/API/Element/localName
Node.nodeName https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeName
Element.tagName https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName

nodeName has the incorrect name casing for checks: "foreignObject" !== "FOREIGNOBJECT". You'll need to fix everywhere that uses NodeData.nameOrCtor.

I'm sorry, I'm not familiar with the idom implementation. I don't understand what I would need to fix.
If the tag name only comes from this line, isn't it self consistent within the algorithm? I don't see any other reference in the codebase to nodeName, localName, or tagName. Are you talking about wiz checks?
Could we just normalize to uppercase here?


Variable Precision Manipulation System

Overview
Precision manipulation widgets.

DRAFT PR

/azp run

Closing draft PR to split into multiple PRs.


Disconnecting from bluetooth

Hi. I bought this esp32 device:
I make everything like in tutorial but I have a problem.
The device randomly disconnected all the time.
What could be a reason this situation?

On my ESP32 via BLE too. BMS make frequently a beep...
How can i set MQTT Update-Interval?

The BMS pushes data every 0.5s. You can use the throttle parameter to skip most of the data:
jk_bms_ble:
  - ble_client_id: client0
    protocol_version: ${protocol_version}
    throttle: 60s

This setting publishes a set of measurements once per minute.
IMO this setting is useless:
    on_passkey_request:
      then:
        - ble_client.passkey_reply:
            id: client0
            passkey: 1234

The BLE module of the BMS is unable to do authentication/encryption.

Thank you. I have delete Passkey. Works too.
I have many notify in my Log:
[09:49:05][D][jk_bms_ble:525]: Unknown168: <IP_ADDRESS>.<IP_ADDRESS>.<IP_ADDRESS>.00.00 (14)
[09:49:05][D][jk_bms_ble:539]: Unknown189: 0x00 0x64
[09:49:05][D][jk_bms_ble:543]: Unknown192: 0x00
[09:49:05][D][jk_bms_ble:545]: Unknown193: 0x00 0xFF (0x00 0x8D)
[09:49:05][D][jk_bms_ble:547]: Unknown195: 0x66 0x40 (0x21 0x40)
[09:49:05][D][sensor:094]: 'jk-bms heating current': Sending state 0.00000 A with 2 decimals of accuracy
[09:49:05][I][jk_bms_ble:570]:   Emergency switch: off
[09:49:05][D][sensor:094]: 'jk-bms temperature sensor 4': Sending state 18.70000 °C with 1 decimals of accuracy
[09:49:05][D][sensor:094]: 'jk-bms temperature sensor 3': Sending state 18.60000 °C with 1 decimals of accuracy
[09:49:05][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:05][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:05][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:05][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:05][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:05][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:06][D][esp32_ble_client:110]: [0] [C8:47:80:16:8D:CE] ESP_GATTC_NOTIFY_EVT
[09:49:06][W][component:237]: Component esp32_ble took a long time for an operation (666 ms).
[09:49:06][W][component:238]: Components should block for at most 30 ms.
ESP_GATTC_NOTIFY_EVT are many times in my log of ESPHome

The BMS pushes data every 0.5s. You can use the throttle parameter to skip most of the data

you mean every 5s (as one would think when seeing 5s) or 0.5s?
5s is fine for me, 0.5s would be overdone. Just asking to clarify.

Correct. See https://esphome.io/guides/configuration-types#config-time

ok, BMS pushes every 0.5s and with 5s in the yaml we reduce the transmit frequency to 5s. I think i got it.

Yes. The notification interval of the BMS cannot be changed and is always 0.5s. The data arrives every 0.5s and we discard most of the incoming data using the throttle option.

thank you, Sebastian.

Thank you too!


lock TP dependency

What does this PR do?
Locks rb-inotify version to be compatible with Ruby version on centos 7.
Fixes #3131
Which TC components are affected by this PR?

[ ] Documentation
[ ] Grove
[ ] Traffic Analytics
[ ] Traffic Monitor
[ ] Traffic Ops
[ ] Traffic Ops ORT
[x] Traffic Portal
[ ] Traffic Router
[ ] Traffic Stats
[ ] Traffic Vault
[ ] Other _________

What is the best way to verify this PR?
./pkg -v traffic_portal_build

Check all that apply

[ ] This PR includes tests
[ ] This PR includes documentation updates
[ ] This PR includes an update to CHANGELOG.md
[ ] This PR includes all required license headers
[ ] This PR includes a database migration (ensure that migration sequence is correct)
[ ] This PR fixes a serious security flaw. Read more: www.apache.org/security

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/2960/
Test PASSed.


ARROW-14942: [R] Bindings for lubridate's dpicoseconds, dnanoseconds, desconds, dmilliseconds, dmicroseconds

This PR adds bindings for lubridate's dseconds, dmilliseconds, dmicroseconds and dnanoseconds.
As picoseconds are not supported by duration in Arrow and duration is of integer type, the call to picoseconds() raises a warning.

@dragosmg ming reviewing this one?

I've been thinking a bit about this. Do you think it's worth having a helper function (to avoid all the repetition), something like make_duration(x, unit)?
Where:
make_duration <- function(x, unit) {
  x <- build_expr("cast", x, options = cast_options(to_type = int64()))
  x$cast(duration(unit))
}

Sure, makes sense 👍  Will do.

@jonkeane I tried to address all the comments and I think the PR is ready for another review.

The errors do not look related ...

Errors do not seem to be related to this PR.


Can't override imageName in cluster to pull image from local registry instead of ghcr

I've set the imageName key in the spec setting to pull from my local registry as my kubernetes cluster doesn't have access to the internet. However, when I spin up the cloudnative-pg cluster the initdb pod tries to pull the image from ghcr.io/cloudnative-pg/postgresql instead of the value I've specified in imageName.
Is there a way to override this value so that the cluster can pull an image from a different source?

@lilambivert take a look at PG cluster CRD spec. You need to edit imageName spec field.


feat(args): set CHANGELOG.md as default missing value for output option

Closes #352

Description

$ git cliff # outputs to stdout

$ git cliff -o # outputs to CHANGELOG.md

$ git cliff -o OTHER_FILE.md # outputs to another file

If -o is given and output path is omitted, output to CHANGELOG.md
For output argument, I set num_args to 0..=1 and default_missing_value to CHANGELOG.md.
Motivation and Context

#352

How Has This Been Tested?

I builded locally and tested with commands like below,
$ cargo build --release
$ target/release/git-cliff                   # printed via console
$ target/release/git-cliff -o                # CHANGELOG.md is generated
$ target/release/git-cliff -o -c cliff.toml  # CHANGELOG.md is generated
$ target/release/git-cliff -o ABC.md         # ABC.md is generated

Screenshots / Logs (if applicable)
Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (no code change)
[ ] Refactor (refactoring production code)
[ ] Other

Checklist:

[x] My code follows the code style of this project.
[x] I have updated the documentation accordingly.
[x] I have formatted the code with rustfmt.
[x] I checked the lints with clippy.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Well.. I started to study Rust for the first time a few hours ago 😂

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (8edec7f) 44.43% compared to head (1ca2f29) 44.43%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #354   +/-   ##
=======================================
  Coverage   44.43%   44.43%
=======================================
  Files          13       13
  Lines         628      628
=======================================
  Hits          279      279
  Misses        349      349

Flag
Coverage Δ

unit-tests
44.43% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


What are the differences between "Creating network architectures which encode solutions" and "addressed by neural architecture search (NAS)" ?

Hello, thank you for your excellent work!
I am really curious about this paragraph in paper.

Creating network architectures which encode solutions is a fundamentally different problem than that addressed by neural architecture search (NAS)

So could you tell me the differences between "Creating network architectures which encode solutions" and "addressed by neural architecture search (NAS)" ?
Thanks a lot.

Let me try to take a stab at your question.
NAS is a technique to search the space of possible architectures, built from a set of building blocks (like CNN kernels, activations etc. for image data), to get the best architecture for the task at hand. This involves, training the networks for a few iterations and evaluating the improvement in performance and only keeping the best performing network(s) to train for longer.
So, as already communicated in the paper, this work is for creating network architectures that have high inductive biases for the task at hand. This means they should be able to perform the task properly right out of the box, with very minimal training of weights. Such a network is thought to be encoding the solutions in its network topology itself, than in weights. This is not the case with architectures that are found using NAS, they are not usually capable of performing the task properly without explicit weight training.
I hope I was able to answer your question. Cheers.


Fix run_me.sh to work on macOS

I got errors running this script on macOS, because the bash version there didn't support the [[ ! -v WASI_SDK_PATH ]] syntax and the date version did not support date --iso-8601=ns.

The CLA web flow there appears to be broken:

Thanks @simonw for contributing this!
We've reported the CLA portal failure to the responsible team. We will ping you once we have an update on that.

Hello @simonw,
Thank you for your contribution! Our internal team mentioned it was a transient issue with the GitHub authentication. Please, could you retry it in a new browser window? It should work now.

Hello @simonw,
Sorry for the long time to reply and thank you for your contribution. After some long discussions, this project is currently in the process of being archived. However, the development of this project will continue as an independent community fork present at https://github.com/webassemblylabs/webassembly-language-runtimes.
We would be grateful if you could recreate your contribution under that fork and we will work on applying it.


Weight conditional probabilities on their distance

Potentially worth investigating whether SNPs closer to the next position are more useful than those that are farther away?

Nah


torchvision version

In requirements, you specify torchvision version equals to 1.12. Do you mean 0.12?

I fixed it with the latest commit


Correct entries, no output

Things to check

Have you forced a refresh in your browser (e.g. ctrl+F5 in Chrome/Firefox)?

yes/no

Have you made sure the first time buyer option is correct? If you're unsure, try it both ways

yes/no

Have you time-travelled this week? Travelling backwards resets the prices, and therefore you must not put prices in from both before & after the time-travel

yes/no

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Permalink to your prices
Please click the Copy Permalink button and paste it here
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Empty issue


fix(demo): Compatible with prettier

see #202

My main concern about this would be it could mislead the user the the string after --- is requires and has some sort of effects (as title or something)

Thanks for contribution. Close due to inactive.


WIP Ingress endpoints: read address from ingress

This PR gets rid of fetching single ip address in the cluster. It's done by 2 reasons:

we derive allNodes=true based on cluster being rke, but even then nginx ingress controller might not be deployed on every node (you can pass node labels now via cluster yml config in the UI)
nginx-ingress is supposed to populate ingress.addresses the same way we do derive address for the node with allNodes=true case.

WIP as we might need to revise the corresponding code in ingress-nginx @orangedeng.

I think we don't need to change anything in nginx-ingress-controller. For now, this controller only populate the IPs which has the nginx daemonset. You can just use the backend IPs in ingress to show the public endpoints.

Since we didn't merge https://github.com/rancher/types/pull/418 yet, feel free to merge this PR. For now, the Nginx-ingress-controller will choose internal IP first if report-node-internal-ip-address is set. And it will use external ip >rke.cattle.io/external-ip > rke.cattle.io/internal-ip.


Deeply nested routes have an exponential impact on compile times

Describe the bug
When nesting routes like so:
#[component]
pub fn App(cx: Scope) -> impl IntoView {
    view! {
        cx,
        <Router>
            <Routes>
                <Route path = "foo" view = Outlet>
                <Route path = "foo" view = Outlet>
                <Route path = "foo" view = Outlet>
- snip -
                    <Route path = "" view = move |cx| view! { cx, "Hi" }/>
- snip -
                </Route>
                </Route>
                </Route>
            </Routes>
        </Router>
    }
}

Compile times increase exponentially when adding more layers. Building a sample app with 3 layers of "wrapper" routes, the crate build time for the app is 2 seconds on my Ryzen 3600. It take 2 seconds again at 4 layers. However, at 5 layers it increases to 4 seconds. 6 layers takes 10 seconds, and 7 layers takes 40 seconds. This also affects cargo check, which causes slowdown in rust-analyser.
In leptos 0.3.1, the same 7 layer sample app builds in 0.93s.
I ran into this issue working on an actual app with 4 layers of wrapper routes, but more complex leaf route views - I am seeing 30 second cargo build / check on 0.4, where I was seeing ~1 second on 0.3.
Leptos Dependencies
leptos = { version = "0.4.1", features = ["csr"] }
leptos_router = { version = "0.4.1", features = ["csr"] }

To Reproduce

Create a new binary crate with leptos and leptos router
Add the following code to main.rs:

use leptos::*;
use leptos_router::*;

#[component]
pub fn App(cx: Scope) -> impl IntoView {
    let outlet = move |cx| view!{ cx, <Outlet/> };

    view! {
        cx,
        <Router>
            <Routes>
                <Route path = "foo" view = outlet>
                <Route path = "foo" view = outlet>
                <Route path = "foo" view = outlet>
                <Route path = "foo" view = outlet>
                <Route path = "foo" view = outlet>
                <Route path = "foo" view = outlet>
                    <Route path = "" view = move |cx| view! { cx, "Hi" }/>
                </Route>
                </Route>
                </Route>
                </Route>
                </Route>
                </Route>
            </Routes>
        </Router>
    }
}

fn main() {
    mount_to_body(|cx| view! {cx, <App/>})
}

Run cargo build --timings
Observe the crate compile time for the app is longer than expected
Add another <Route> layer
Run cargo build --timings
Observe the crate compile time for the app doubles or more
Switch the leptos dependencies to 0.3.1
Observe the crate compile time returns to normal

Expected behavior
App compile time does not grow exponentially when deeply nesting routes.

Yikes. I'll take a look. Any help narrowing this down to a particular commit or to some point between 0.3.0 and 0.4.0 would be very much appreciated.

I did a quick manual bisect, and it seem to have been introduced here: https://github.com/leptos-rs/leptos/commit/17adf7cc1467aa1ddd41ffa16fcd3c438068bb98

Thanks so much, that's very helpful. That certainly makes sense as it is making some significant change to the way the compiler thinks about components.

I spent a little time exploring this, this afternoon. Interestingly, it looks like it doesn't affect release mode, at least not in anything close to an exponential way; i.e., going from 10 to 20 deep brought me from 5s to 10s compile time in release mode.
Otherwise, everything in that commit is just sort of a changing around how our trait magic works and adding some trait implementations. So it's hard for me to figure out how to address the compile-time issue.

After some testing, I've identified a workaround. Moving the deepest routes into a closure that gets called resolves the compile time issue:
    let routes = move || view! {
        cx,
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
            <Route path = "" view = move |cx| view! { cx, "Hi" }/>
        </Route>
        </Route>
        </Route>
        </Route>
        </Route>
        </Route>
    };

    let routes = move || view! {
        cx,
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
        <Route path = "foo" view = outlet>
            {routes()}
        </Route>
        </Route>
        </Route>
        </Route>
        </Route>
        </Route>
    };

    view! {
        cx,
        <Router>
            <Routes>
                [routes]
            </Routes>
        </Router>
    }

I tried not calling the closure, which compiled, but panicked - presumably the routes must be defined once and can't be updated dynamically.
Interestingly, inlining the function (i.e. nesting the view macro) still causes long compile times.

This is also discussed here: https://discord.com/channels/1031524867910148188/1135202584672608277


fix: handle additional args in components' with event modifiers

Additional args are not passed to components events with modifiers.
with a component template like this
<input @keyup="$emit('my-keyup', $event, var1, var2)"/>
triggering the event, e.g.
<my-component @my-keyup.enter="onMyKeyup"/>
the onMyKeyup receives the $event, but not var1 and var2
hope this PR resolves the issue.

What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[x] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[x] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

No need of additional args, you can achieve it using an object instead.
<input @keyup="$emit('my-keyup', **object**)"/>
Where your object looks like :
{      event: $event,     var1: var1,     var2: var2, }

@sopegue,
Thank you for your comment,
Digging into the code revealed that .enter modifier is checked by something like if (aruments[0].keyCode == 13) so { event: $event, var1: var1, var2: var2, } will not work.
Simply put, to use event modifier in a component, e.g., @my-keyup.enter, $event need to be passed as the first argument, and surprisingly, the rest is ignored.

I tried your previous attempt and my  solution, both work properly locally and in production.
The event sill fire even if not enter key pressed.
However, tried it on codesandbox but did not work, wondering why...

The codesandbox with your solution raises Cannot read property 'indexOf' of undefined" which is probably rooted in getKeyFilter where checks the existence of key in $event, i.e., if(!$event.type.indexOf('key') ... return null. In your code, $event is set as { event: $event, var1, var2 } that does not include the key.
Although it does not resolve the issue, to get rid of the error, you may add key, keyCode, target to the object. Please see codesandbox

Duplicate of https://github.com/vuejs/vue/pull/10958


Hotfix for missing tailwind.css dependency

Pull Request Description
This PR add a fix for Resource not found: tailwind.css file
Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[ ] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@PabloBuchu, how was the PR merged that caused the build failing with this message? Was QA done in that PR?


Is someone experiencing this? please let me know!

anyone have this problem? the code, for me, is having a problem as of today. i.e. it gets stuck HERE and then hangs "forever" until the microphone is muted\disabled manually. at that point, when you turn off the mic manually, then it unlocks and print the text you spoke. It never did it before, I hope it's only happening to me, if it happens to you too let me know

basically, for me to make it work now, I need:

speak (with the microphone on)
turn off the microphone to print the text and continue running the program

Until I turn off the mic keep listening "forever"

alsa force-reload fix the problem


Should I freeze norm.weight?

Llama base model has norm.weight.
Did you also freeze norm.weight when post-training?
    "model.layers.9.self_attn.o_proj.weight": "model-00001-of-00004.safetensors",
    "model.layers.9.self_attn.q_proj.weight": "model-00001-of-00004.safetensors",
    "model.layers.9.self_attn.v_proj.weight": "model-00001-of-00004.safetensors",
    "model.norm.weight": "model-00004-of-00004.safetensors"

We freeze all the weights of the initial llama model and only train the newly added blocks.


ML 2.1 : What is Learning? Why Machine Learning works? (D)

…(D).md

Description 📜
Made documentation on the topic What is Learning? Why Machine Learning works?
Fixes #3190

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Machine #Learning

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

There aren't any references for the images/other content you borrowed from anywhere.

@Isha307 , I have made the changes can you please merge the PR.
Akshay Sir all the changes addressed sir.

Changes done properly. PR merged 🎉 @ashish-reddy-20-08


Give option for filter to include only certain resources

Feature name
Give option for filter to include only certain resources
Is your feature request related to a problem? Please describe.
Currently the filter allows you to exclude resource type but if I want to look at say a VPC but only look at the subnets, route tables and security groups I would have to select every resource I didn't want to see.
Describe the feature you'd like to see implemented
I would like to have the option to select only the resources I'm interested in rather than having to explicitly exclude all the ones I don't want.
Describe the value this feature will add to AWS Perspective
It will improve the UI by making it easier to make very targeted diagrams.
Describe alternatives you've considered
The only way to do this is to click to exclude all the resources I don't want.

Would be nice to have a quick/easy way to exclude all resources related to the AWS Perspective tool itself.

This would be great! We have multiple pseudo environments within a single account, with tags used to identify them. By being able to filter by tags we could limit the resources in our architectural diagrams to our staging/development/production resources only. Right now, if we were to look at a single logical grouping of services it picks up all of the production and staging services in a single chart, showing duplicates of each resource.

You should be able to search for a specific tag in the search bar and it will bring up only those resources tagged with that specific tag.

@svozza Thanks, I've used this on some of our searches, however, we actually have multiple tags that I need to filter on. For example, I would like to filter on a project tag and a psuedo-environment tag, which I don't believe I can do currently.

Ah I ssee what you mean, I can see how being able to combine filters would be useful in that case.


ci: Cleanup Service Integration Tests

ci: Cleanup Service Integration Tests

ping @Xuanwo to add integration tests in teamcity.

Done: https://teamcity.beyondstorage.io/project/Services_Dropbox?mode=trends


do not run api comparison checks in build phase

should only happen in verify/test phase
this avoids problems with module reorg across versions

Possibly a more structured fix is to make sure the japicmp plugin is only run as part of the 'compliance' profile, but right now I just want a quick fix to get the branches stable again, and the 3.5 release out the door.


Permission denied & CLI Process died while starting Pytg

The problem
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/pytg/__init__.py", line 33, in __init__
    self.start_cli(telegram=telegram, pubkey_file=pubkey_file, custom_cli_args=custom_cli_args, port=port)
  File "/usr/local/lib/python3.5/dist-packages/pytg/__init__.py", line 86, in start_cli
    self._proc = subprocess.Popen(args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, preexec_fn=preexec_function)
  File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
    raise child_exception_type(errno_num, err_msg)
PermissionError: [Errno 13] Permission denied

All folders of tg-cli are chmod-ed with 777 permission and the file is runned by sudo.
EDIT: Fixxed by doing tg = Telegram(telegram="/home/marcobuster/tg-cli/tg/bin/telegram-cli", pubkey_file="/home/marcobuster/tg-cli/tg/tg-server.pub")
Now I have this problem:
INFO:pytg:Starting Telegram Executable: "/home/marcobuster/tg-cli/tg/bin/telegram-cli -R -W -P 4458 -k /home/marcobuster/tg-cli/tg/tg-server.pub --json --permanent-peer-ids --permanent-peer-ids"
DEBUG:pytg.sender:Parsing raw: Argument help - <command> (needed)
DEBUG:pytg.sender:Sending command >[disable_preview]  help
<
INFO:pytg:CLI did not responde.
DEBUG:pytg.sender:Parsing raw: Argument help - <command> (needed)
DEBUG:pytg.sender:Sending command >[disable_preview]  help
<
INFO:pytg:CLI did not responde.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/pytg/__init__.py", line 52, in __init__
    raise AssertionError("CLI Process died.")
AssertionError: CLI Process died.

Your environment
I'm using Python 3.5.2 on Linux Ubuntu 16.04.
Steps to reproduce
Import pytg
from pytg import Telegram

Inizialize a Telegram object
tg = Telegram(telegram="/home/marcobuster/tg-cli/tg/", pubkey_file="/home/marcobuster/tg-cli/tg/tg-server.pub")

Please turn on verbose logging:
https://github.com/luckydonald/pytg#in-case-of-errors

Oh, I have fixxed by doing this:
tg = Telegram(telegram="/home/marcobuster/tg-cli/tg/bin/telegram-cli", pubkey_file="/home/marcobuster/tg-cli/tg/tg-server.pub")

But now I have this problem:
INFO:pytg:Starting Telegram Executable: "/home/marcobuster/tg-cli/tg/bin/telegram-cli -R -W -P 4458 -k /home/marcobuster/tg-cli/tg/tg-server.pub --json --permanent-peer-ids --permanent-peer-ids"
DEBUG:pytg.sender:Parsing raw: Argument help - <command> (needed)
DEBUG:pytg.sender:Sending command >[disable_preview]  help
<
INFO:pytg:CLI did not responde.
DEBUG:pytg.sender:Parsing raw: Argument help - <command> (needed)
DEBUG:pytg.sender:Sending command >[disable_preview]  help
<
INFO:pytg:CLI did not responde.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/pytg/__init__.py", line 52, in __init__
    raise AssertionError("CLI Process died.")
AssertionError: CLI Process died.

This usually means the CLI terminated. It shouldn't have done that.

You can also look for the telegram progress in tools like top (some prefer htop).
Also try what happens if you execute the same arguments you can find in the debug, look for Starting Telegram Executable.
In your case that would be
home/marcobuster/tg-cli/tg/bin/telegram-cli -R -W -P 4458 -k /home/marcobuster/tg-cli/tg/tg-server.pub --json --permanent-peer-ids --permanent-peer-ids

See if that works.
Next you can try the commands it sends yourself.
See Sending command >command< in the debug log.


Build Errors

I am a first-time contributor to this project, but I must be missing something.  The guidelines state: "Make sure you can build the code."  But when I try to build the Mvc solution, I get a LOT of build errors -- 564, to be precise.
I would like to submit a pull request for issue #1744, but I'm stuck on the build errors, especially CS1061, which is taking place in Microsoft.AspNet.Mvc, MvcServiceCollectionExtensions, complaining that 'IServiceCollection' does not contain a definition for 'AddAuthorization'.  Any help would be greatly appreciated.

I'm looking at the packages here: https://www.myget.org/gallery/aspnetvnext.  And I see that Microsoft.AspNet.Security is at version v1.0.0-beta3-11421, but if I drill down into the References node for SP.NET 5.0, I can see that the version is shown as v1.0.0-rc1-11390, which is strange because project.json for Microsoft.AspNet.Mvc.Core contains a dependency for "Microsoft.AspNet.Security": "1.0.0-*".  I'm wondering if there is a precedence issue with the version numbers?

It turned out the issue was caused by version number precedence.  So all I had to do was make sure my NuGet settings had just two feeds: nuget.org and AspNetVNext (https://www.myget.org/F/aspnetvnext/api/v2).  Then I cleared all packages from my local store: %UserProfile%.kpm\packages.  Then I opened a command prompt, navigated to the local Mcv repo and ran: kpm restore.
I was then able to build the Mvc solution without errors.  I hope this will help someone else who may run into the same problem.

After pulling in the latest upstream (v1.0.0-beta4-10246), I ran kvminstall.ps1 and kvm upgrade.  However, the KRE is still on 1.0.0-beta3-10921.
Then I cleared by .kpm\packages folder, and ran kpm restore for the Mvc global.json.  But when I tried to build the Mvc.sln, I received 99 build errors -- all of them stating:
ASP.NET 5.0 error CS1061: 'IRouteBuilder' does not contain a definition for 'MapRoute' and no extension method 'MapRoute' accepting a first argument of type 'IRouteBuilder' could be found (are you missing a using directive or an assembly reference?)
Obviously, there must be a version mismatch somewhere causing the build to break.  Any ideas on how to resolve this?

I figured out how to install the 1.0.0-beta4-10946 runtime by installing dotnetsdk and calling upgrade.  But the Mvc project build still fails with the same errors.

It looks like a change to the namespace for the MapRoute extension is what broke the Mvc build:
https://github.com/aspnet/Routing/commit/29a5cb8aa9bfda4883545f6f1b7c00e52d9b4b55.

It turns out kpm restore was not pulling down the version of AspNet/Routing with the namespace change in it.  However, I tried clearing and restoring packages today, and I've got version 1.0.0-beta4-10996 with the change, and everything compiles just fine now. :smile:


Greedy field template fixes

Coverage increased (+0.02%) to 92.537% when pulling 6b106f950fdf6c01cd5eade094aa890a194047dd on greedy_field into 9d6bd44dff8ecd02752f67452c29c403df4f5fe0 on master.