Djbsort: A new software library for sorting arrays of integers • Hacker News Board

Re: Djbsort: A new software library for sorting arrays of integers

#41

Post by nrclark » Wed, Jul 11, 2018, 12:59 PM UTC

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer.

Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths?

I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a build flow that involves:

  1. Downloading a text file
  2. Parsing it to get a URL
  3. Making a new user
  4. Symlinking the user's HOME directory into the build tree
  5. Run an extremely non-standard build system.
  6. Hope you're not trying to cross-compile, because good luck with that.
  7. Guess at where the files came out (hint: it probably won't be in FHS locations)
  8. Copy the output yourself once you find it.

Would it really be that much harder to give us a git repo and a ./configure or a CMakeLists.txt?

Re: Djbsort: A new software library for sorting arrays of integers

#42

Post by josteink » Wed, Jul 11, 2018, 1:01 PM UTC

ben0x539 wrote: post #25

banachtarski wrote: post #8

Earlier quoted context omitted.

Unrelated to the article I recently learned Go just as a side-interest. I was appalled by how terrible the language is. Usually, language warts aren't apparent until you use it a bit but here annoyances were present on day 1 and never went away.

Some of the stuff that makes it work is unfortunately apparent later than the warts. Try to think of it as a domain-specific language for implementing simple http endpoints. ¯\_(ツ)_/¯

> Try to think of it as a domain-specific language for implementing simple http endpoints.

But to that type-safe and well, you probably want Generics.

Re: Djbsort: A new software library for sorting arrays of integers

#43

Post by stochastic_monk » Wed, Jul 11, 2018, 1:04 PM UTC

yoklov wrote: post #13

The problem with AVX2 accelerated code (and much of AVX) is that unless you have a lot of it to run you end up with a substantial speed hit that comes from the cost of switching to a different power bin (which often takes 1 or 2ms!) and then running at a lower clock speed. This often still ends up being an improvement over scalar code (at the cost of higher power usage), but for occasional workloads that don't need t…

So in a sense, using wider vectors should be done at times when you’re certain to need heavy lifting, much like a GPU, but at a smaller timescale. I should update my vectorization library so that it doesn’t simply use the widest possible.

Re: Djbsort: A new software library for sorting arrays of integers

#44

Post by jerf » Wed, Jul 11, 2018, 1:17 PM UTC

thenrich99 wrote: post #27

banachtarski wrote: post #8

Earlier quoted context omitted.

Unrelated to the article I recently learned Go just as a side-interest. I was appalled by how terrible the language is. Usually, language warts aren't apparent until you use it a bit but here annoyances were present on day 1 and never went away.

Go is a language that's easy to use, but a challenge for beginners to use well , especially if you try to force [insert another language] constructs into it. I see programmers that are new to Go often struggle with trying to apply their object-oriented mindset into a language that's not object-oriented and run into trouble, complain about the language, and call it rubbish. Or, focus on the lack of generics and other…

"Go is a language that's easy to use, but a challenge for beginners to use well, especially if you try to force [insert another language] constructs into it."

Strongly agreed. There's a lot of languages out there with very rich feature sets, and the way you get jobs done is to go find the right feature you need for your current problem. With Go, you need to learn the language and extract every last drop out of every language feature. This is exacerbated by the fact that the feature set isn't what people expect, e.g., object composition is not what they are used to, and while interfaces are simple there's still some art to using them properly.

Despite the vast, vast distance between Go and Haskell on the general-purpose programming language landscape, I found my experiences in Haskell to be quite useful in Go, because while they were specifically inapplicable to an imperative language, the general practice I got from Haskell of taking a bizarre set of programming tools and learning how to make sensible programs out of them even so was quite useful.

(It isn't necessarily the first language I reach for for personal tasks, but it is a superb professional programming language, offering a nearly-unique blend of the ability to get the job done you usually need to do for a wide variety of standard programming tasks (but not all!) while resulting in source code that is still comprehensible to almost every programmer. It isn't my favorite overall, but it's the best professional choice of language I have in my belt, which is often precisely because it does not permit me to indulge in flights of clever fancy that solves a problem in 25 impenetrable-to-the-next-guy lines of code. I know a lot of people may not love to hear that, but it's a factor you really have to consider when you are being paid to solve problems.)

Re: Djbsort: A new software library for sorting arrays of integers

#45

Post by jonlandrum » Wed, Jul 11, 2018, 1:17 PM UTC

Am I the only one who thought the name had something to do with Djibouti?

Re: Djbsort: A new software library for sorting arrays of integers

#46

Post by geocar » Wed, Jul 11, 2018, 1:23 PM UTC

nrclark wrote: post #41

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer. Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths? I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a bu…

> Why do I need ... assumptions about system paths?

> what is the rationale for a build flow that involves:

It solves problems.

https://cr.yp.to/compatibility.html

https://cr.yp.to/slashpackage/studies.html

https://cr.yp.to/slashpackage/finding.html

https://cr.yp.to/slashpackage/sharability.html

> Would it really be that much harder to give us a git repo and a ./configure or a CMakeLists.txt?

Yes.

Re: Djbsort: A new software library for sorting arrays of integers

#47

Post by textmode » Wed, Jul 11, 2018, 1:26 PM UTC

pushcx wrote: post #31

The library doesn't have a license on the site or in the tarball. From djb's previous writing and software, he probably intends it to be license-free software, which is an uncommon situation worth investigating before use: https://en.wikipedia.org/wiki/License-free_software (Trying to describe this neutrally because I've seen enough bickering about it over the last ~20 years and don't have strong feelings about it.)

https://twitter.com/hashbreaker/status/1016951373005455360

Re: Djbsort: A new software library for sorting arrays of integers

#48

Post by nrclark » Wed, Jul 11, 2018, 1:36 PM UTC

geocar wrote: post #46

nrclark wrote: post #41

My job involves a lot of packaging/cross-compilation, and djb's libraries always seem consistently hostile to the lowly packaging engineer. Would it really be all that much work to package in autotools or CMake? Why do I need his special-snowflake build system with its hard-coded assumptions about system paths? I know that the cult of djb will downvote this into oblivion, but seriously, what is the rationale for a bu…

> Why do I need ... assumptions about system paths? > what is the rationale for a build flow that involves: It solves problems. https://cr.yp.to/compatibility.html https://cr.yp.to/slashpackage/studies.html https://cr.yp.to/slashpackage/finding.html https://cr.yp.to/slashpackage/sharability.html > Would it really be that much harder to give us a git repo and a ./configure or a CMakeLists.txt? Yes.

FWIW, I read through each of your links. They don't address cross-compilation at all, or the needs of software packagers.

I can 100% promise you that somebody packaging this library for any Linux distro (or for a Yocto/Buildroot system) would grind their teeth in frustration at everything in the those links.

The solution to having inconsistent packaging paths isn't to introduce _yet another_ packaging path system, but this one specific to djb stuff. It's to use a standard build system with overrideable paths, and not to assume the author knows better than the packager.

Re: Djbsort: A new software library for sorting arrays of integers

#49

Post by JdeBP » Wed, Jul 11, 2018, 1:38 PM UTC

> Other modern Linux/BSD/UNIX systems should work with minor adjustments to the instructions.

I can report that I got it to build and run on slightly out of date FreeBSD by deleting all of the -m32 variants, and deleting all of the -march=haswell variants. I haven't looked into whether this is down to the version of GCC that comes in ports and the version of Clang that comes in base, or something else. No other changes were needed to the build process, though.

    JdeBP /package/prog/djbsort % /tmp/djbsort/command/int32-speed
    int32 implementation int32/portable4
    int32 version -
    int32 compiler clang -fPIC -Wall -O2 -fomit-frame-pointer -fwrapv
    int32 1 72 72 72
    ...
    int32 1048576 1979077401 1979993070 1983745962

Re: Djbsort: A new software library for sorting arrays of integers

#50

Post by amorousf00p » Wed, Jul 11, 2018, 1:42 PM UTC

Create a user and env to run a one-off build + application. DJB cracks me up. He may have the right thing in mind but this type of prophylactic approach is no longer proof against anything.