Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Full Unicode Search at 50× ICU Speed with AVX‑512

ashvardanian.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#51

Post by fatty_patty89 »

kbolino wrote: post #43
fatty_patty89 wrote: post #26

Earlier quoted context omitted.

In a normal world the Go C FFI wouldn't have insane overhead but what can we do, the language is perfect and it will stay that way until morale improves. Thanks for the work you do

There are undoubtedly still some optimizations lying around, but the biggest source of Go's FFI overhead is goroutines. There's only two "easy" solutions I can see: switch to N:N threading model or make the C code goroutine-aware. The former would speed up C calls at the expense of slowing down lots of ordinary Go code. Personally, I can still see some scenarios where that's beneficial, but it's pretty niche. The lat…

Java has green threads and c#/.net has logical threads

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#52

Post by infogulch »

bigwheels wrote: post #49
bee_rider wrote: post #46

Earlier quoted context omitted.

They seem to have (if I understand correctly) degree-Celsius and degree-Fahrenheit symbols. So maybe Kelvin is included for consistency, and it just happens to look identical to Latin K? IMO the confusing bit is giving it a lower case. It is a symbol that happens to look like an upper case, not an actual letter…

And why can't the symbol be a regular old uppercase "K"? Who is this helping?

Unicode wants to be able to preserve round-trip re-encoding from this other standard which has separate letter-K and degree-K characters. Making these small sacrifices for compatibility is how Unicode became the defacto world standard.

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#53

Post by kbolino »

fatty_patty89 wrote: post #51
kbolino wrote: post #43

Earlier quoted context omitted.

There are undoubtedly still some optimizations lying around, but the biggest source of Go's FFI overhead is goroutines. There's only two "easy" solutions I can see: switch to N:N threading model or make the C code goroutine-aware. The former would speed up C calls at the expense of slowing down lots of ordinary Go code. Personally, I can still see some scenarios where that's beneficial, but it's pretty niche. The lat…

Java has green threads and c#/.net has logical threads

Yes, I have cleaned up the wording a bit. Also, the common implementation of Rust's async is comparable to green threads, and I think Zig is adopting something like it too.

However, the "normal" execution model on all of them is using heavyweight native threads, not green threads. As far as I can tell, FFI is either unsupported entirely or has the same kind of overhead as Go and Erlang do, when used from those languages' green threads.

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#54

Post by happytoexplain »

Sesse__ wrote: post #40
jjmarr wrote: post #24

Earlier quoted context omitted.

> I find it confusing when Unicode "shadows" of normal letters exist, and those are of course also dangerous in some cases when they can be mis-interpreted for the letter they look more or less exactly like Isn't this why Unicode normalization exists? This would let you compare Unicode letters and determine if they are canonically equivalent.

It's why the Unicode Collation Algorithm exists. If you look in allkeys.txt (the base UCA data, used if you don't have language-specific stuff in your comparisons) for the two code points in question, you'll find: 004B ; [.2514.0020.0008] # LATIN CAPITAL LETTER K 212A ; [.2514.0020.0008] # KELVIN SIGN The numbers in the brackets are values on level 1 (base), level 2 (typically used for accents), level 3 (typically us…

Are the meanings for the levels for each code point defined somewhere (accent, casing, etc)?

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#55

Post by fatty_patty89 »

kbolino wrote: post #53
fatty_patty89 wrote: post #51

Earlier quoted context omitted.

Java has green threads and c#/.net has logical threads

Yes, I have cleaned up the wording a bit. Also, the common implementation of Rust's async is comparable to green threads, and I think Zig is adopting something like it too. However, the "normal" execution model on all of them is using heavyweight native threads, not green threads. As far as I can tell, FFI is either unsupported entirely or has the same kind of overhead as Go and Erlang do, when used from those langua…

Genuine question, you make it seem as this is a limitation and they're all in the same bucket but how was Java for example able to scale all the enterprises while having multi threading and good ffi, same with .net.

My impression is that the go ffi is with big overhead because of the specific choices made to not care about ffi because it would benefit the go code more?

My point was that there's other gc languages/envorionments that have good ffi and were somehow able all these decades to create scalable multithreaded applications.

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#56

Post by shiomiru »

infogulch wrote: post #52
bigwheels wrote: post #49

Earlier quoted context omitted.

And why can't the symbol be a regular old uppercase "K"? Who is this helping?

Unicode wants to be able to preserve round-trip re-encoding from this other standard which has separate letter-K and degree-K characters. Making these small sacrifices for compatibility is how Unicode became the defacto world standard.

The "other standard" in this case being IBM-944. (At least looking at https://www.unicode.org/versions/Unicode1.0.0/ch06.pdf p. 574 (=110 in the PDF) I only see a mapping from U+212A to that one.)

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#57

Post by zygentoma »

bee_rider wrote: post #50
bigwheels wrote: post #49

Earlier quoted context omitted.

And why can't the symbol be a regular old uppercase "K"? Who is this helping?

I think just using uppercase Latin K is the recommendation. But, I dunno. Why would anybody apply upper or lower case operators to a temperature measurement? It just seems like a nonsense thing to do.

Maybe not for text to be read again, but might be sensible e.g. for slug or file name generation and the like...

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#58

Post by Eisenstein »

bee_rider wrote: post #50
bigwheels wrote: post #49

Earlier quoted context omitted.

And why can't the symbol be a regular old uppercase "K"? Who is this helping?

I think just using uppercase Latin K is the recommendation. But, I dunno. Why would anybody apply upper or lower case operators to a temperature measurement? It just seems like a nonsense thing to do.

I wonder if you can register a domain with it in the name.

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#59

Post by dboon »

ashvardanian wrote: post #19

This article is about the ugliest — but arguably the most important — piece of open-source software I’ve written this year. The write-up ended up long and dense, so here’s a short TL;DR: I grouped all Unicode 17 case-folding rules and built ~3K lines of AVX-512 kernels around them to enable fully standards-compliant, case-insensitive substring search across the entire 1M+ Unicode range, operating directly on UTF-8 by…

This is exactly the kind of thankless software which the world operates on. It’s unfortunate that such fundamental code hasn’t already been vectorized or the gills, but thank you for doing so! It’s excellent work

Re: Full Unicode Search at 50× ICU Speed with AVX‑512

#60

Post by neonsunset »

fatty_patty89 wrote: post #51
kbolino wrote: post #43

Earlier quoted context omitted.

There are undoubtedly still some optimizations lying around, but the biggest source of Go's FFI overhead is goroutines. There's only two "easy" solutions I can see: switch to N:N threading model or make the C code goroutine-aware. The former would speed up C calls at the expense of slowing down lots of ordinary Go code. Personally, I can still see some scenarios where that's beneficial, but it's pretty niche. The lat…

Java has green threads and c#/.net has logical threads

[dead]
Post reply on HN