Hacker News Reader

Comment by vardump | Hacker News Reader

Pretty nice. Always nice to see better optimized commonly required algorithms. If this is really faster than previous implementations (no reason to doubt, but don't have time to validate right now), this might save megawatts of power world wide. (Disclaimer: Would need to actually check with power measurement tools, but generally faster consumes less power.)

A small nitpick: not sure whether those macros bought anything, I guess the optimizer could inline function calls to intrinsic wrappers just fine as well?

View on HN

> this might save megawatts of power world wide

That'd sure be neat! I really have no idea, though.

> A small nitpick: not sure whether those macros bought anything, I guess the optimizer could inline function calls to intrinsic wrappers just fine as well?

Yeah, that's a bit weird. It's my hacky generics-in-C method, that allows both AVX2 and SSE4 implementations to be compiled in one codebase, while keeping the base algorithm clean. The idea is that you can compile both versions by including multiple times, like so:

  #define AVX2
  #include "z_validate.c"
  #undef AVX2
  #define SSE4
  #include "z_validate.c"
  #undef SSE4

...which would allow a later runtime dispatch based on CPUID, etc.

How much faster than a "naive" scalar implementation is this?

It depends on the implementation. A good starting point would be looking at the various implementations benchmarked here: https://github.com/lemire/fastvalidate-utf-8

It looks like the main naive validator there (validate_utf8) clocks in at 1.25 cycles/byte for ASCII and 11 cycles/byte for UTF-8, which is respectively a 15.8x and 41.5x slowdown from my code.

...this might save megawatts of power world wide...

Since when saved megawatts bothered programmers? If that was the case we would see far smaller usage of scripting languages and electron apps.

It takes effort to not use electron. It doesn't take effort to have your library update its dependencies to use a faster utf-8 validator

> It takes effort to not use electron.

Why do you believe this? I don't think it is quite that ubiquitous.

Let's say I want to build a cross-platform app. I could use Electron (it's somewhat of a known quantity), or I could start doing some research into what else is available, and then evaluate the various offerings - not only to ensure they do what I need, but to also ensure that they use less power/resources than Electron. The effort here is (at least some kind of) unavoidable up-front cost/time.

To switch existing code to use some particular UTF-8 decoding library should be as simple as changing some imports, and perhaps some other (search/replace) code tweaks or implementing a quick shim/adapter. If it doesn't work out, rollback or abandon the branch. On most codebases, even larger ones, this whole process is probably an easier thing to do, requiring less effort than finding a decent (and more power efficient) alternative to Electron — seems to be the GP's gist. And personally I'd agree.

"Let's say I want to build a cross-platform app. I could use Electron (it's somewhat of a known quantity), or I could start doing some research into what else is available, and then evaluate the various offerings - not only to ensure they do what I need, but to also ensure that they use less power/resources than Electron. The effort here is (at least some kind of) unavoidable up-front cost/time."

Yup that's right. Any sign of inconvenience and efficiency be damned. Why do we even bother trying to fix environment. This cost money and inconveniences so many people.

Also it depends on your background. I have no problem doing without Electron. I would have to apply your exact logic to even look at it.

You are clearly someone seeing in black and white. There's shade of grays too, you know?

> Any sign of inconvenience and efficiency be damned.

Nope, not any signs... just that if you can build more with less time, in exchange of a bit of CPU efficiency, it's not so bad.

> Why do we even bother trying to fix environment.

For the future. You see, my program using a bit more RAM or CPU won't change much. Not eating that meat, that will change quite a bit, thus that's one of the things I do.

A software can allow people to be many orders in magnitudes more efficient, if I can build more of them, it allows even more people to be a few orders of magnitude more efficient. The power usage afterward, fit in the error margin quite well.

It's not quite that simple. A different algorithm and/or some well placed caching can easily outweigh the difference between a fast compiled (i.e. probably more efficient) language and slower interpreted one.

Obviously, a more efficient language with a better algorithm and good caching is best, but often we don't have the resources (whether it be time or money or whatever) to engineer the best solution, so we need to choose where to focus carefully. Sometimes that means faster prototyping in a language that may not be quite as efficient, and then using the extra time to iterate on algorithmic changes that may yield major benefits or put a caching layer in place.

"programmers" are not a single uniform homogeneous group and it is dismissive to consider them as such.

I'm a programmer and I care.

Me too ;) But I think we are in minority here

Reply on news.ycombinator.com