{"action":"created","issue":{"url":"https://api.github.com/repos/rust-lang/rust/issues/55559","repository_url":"https://api.github.com/repos/rust-lang/rust","labels_url":"https://api.github.com/repos/rust-lang/rust/issues/55559/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rust/issues/55559/comments","events_url":"https://api.github.com/repos/rust-lang/rust/issues/55559/events","html_url":"https://github.com/rust-lang/rust/issues/55559","id":376215390,"node_id":"MDU6SXNzdWUzNzYyMTUzOTA=","number":55559,"title":".count() too slow","user":{"login":"npip99","id":8939474,"node_id":"MDQ6VXNlcjg5Mzk0NzQ=","avatar_url":"https://avatars1.githubusercontent.com/u/8939474?v=4","gravatar_id":"","url":"https://api.github.com/users/npip99","html_url":"https://github.com/npip99","followers_url":"https://api.github.com/users/npip99/followers","following_url":"https://api.github.com/users/npip99/following{/other_user}","gists_url":"https://api.github.com/users/npip99/gists{/gist_id}","starred_url":"https://api.github.com/users/npip99/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/npip99/subscriptions","organizations_url":"https://api.github.com/users/npip99/orgs","repos_url":"https://api.github.com/users/npip99/repos","events_url":"https://api.github.com/users/npip99/events{/privacy}","received_events_url":"https://api.github.com/users/npip99/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2018-11-01T01:05:49Z","updated_at":"2018-11-06T10:44:02Z","closed_at":null,"author_association":"NONE","body":"I noticed something peculiar in #33038, notably\r\n\r\n> So in short, the slowdown is caused by .count() using 64 bit integers. Which is strange, because the length of the vector is known be less than 2^32 - is there any way to optimize Vec or count() to use something smaller than usize?\r\n\r\nIn my understanding, `.count()` using `usize` directly contradicts\r\n\r\n> So how do you know which type of integer to use? If you’re unsure, Rust’s defaults are generally good choices, and integer types default to i32: this type is generally the fastest, even on 64-bit systems. The primary situation in which you’d use isize or usize is when indexing some sort of collection.\r\n\r\nfrom https://doc.rust-lang.org/book/second-edition/ch03-02-data-types.html\r\n\r\n`.count()` is certainly never realistically being used for indexing, so according to the above paragraph it should default to `i32` on 64bit systems (This is referring to automatic typing of integer literals, but as an idea it remains valid). If this was already thoroughly discussed, I apologize. If not, I think it needs a second look. I think that in the majority of use cases, the users of Rust would much prefer `.count()` be three times faster, as opposed to being able to surpass 4 Billion."},"comment":{"url":"https://api.github.com/repos/rust-lang/rust/issues/comments/436209515","html_url":"https://github.com/rust-lang/rust/issues/55559#issuecomment-436209515","issue_url":"https://api.github.com/repos/rust-lang/rust/issues/55559","id":436209515,"node_id":"MDEyOklzc3VlQ29tbWVudDQzNjIwOTUxNQ==","user":{"login":"npip99","id":8939474,"node_id":"MDQ6VXNlcjg5Mzk0NzQ=","avatar_url":"https://avatars1.githubusercontent.com/u/8939474?v=4","gravatar_id":"","url":"https://api.github.com/users/npip99","html_url":"https://github.com/npip99","followers_url":"https://api.github.com/users/npip99/followers","following_url":"https://api.github.com/users/npip99/following{/other_user}","gists_url":"https://api.github.com/users/npip99/gists{/gist_id}","starred_url":"https://api.github.com/users/npip99/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/npip99/subscriptions","organizations_url":"https://api.github.com/users/npip99/orgs","repos_url":"https://api.github.com/users/npip99/repos","events_url":"https://api.github.com/users/npip99/events{/privacy}","received_events_url":"https://api.github.com/users/npip99/received_events","type":"User","site_admin":false},"created_at":"2018-11-06T10:44:02Z","updated_at":"2018-11-06T10:44:02Z","author_association":"NONE","body":"The IR is bad. You can see it calling ctpop just once on an element, and then comparing to 15 just once. Then it does that 4 times, iterating a total of four times (I suppose it decided 4 was a good unroll). All of those ctpops and cmp eq 15's could be done four at a time using xmm. That would lead to 16 iterations by the end, not 4. That's what the 32bit IR does. The counting is good as you said; what is bad is that for some reason vectorization of the closure broke. The counting in fact has nothing to do with the runtime, it just had a side effect of unvectorizing the closure's IR for some reason."}}
{"actor":{"display_login":"npip99"}}