jandrewrogers
Much of the difference in optimizability is that C/C++
allows you to do fairly extreme copy elision. This is
important because memory bandwidth tends to be a major
performance bottleneck.C/C++ code can trivially reach into
some remote bit of state and mutate it directly. The
compiler rarely objects, no matter how ugly the access
method or pattern. It is up to the programmer to make sure
the invariants hold and the compiler can't always see
through it. These elided copies add up, though it usually
has a maintainability and safety cost.It is related to why
functional languages tend to be mediocre for
supercomputing in practice despite having nice properties
for massive parallelism in theory.
|
> whilenot-dev
That's a nice explanation, thanks.Are there any common
resources for this kind of access methods and patterns
that specifically aim to bridge the soft-/hardware
gap? The best one I can come up with is Performance
Analysis and Tuning on Modern CPUs[0] by Denis
Bakhvalov.[0]: https://github.com/dendibakh/perf-book
|
VorpalWay
> lean-zip beats every single compression level
miniz_oxideMiniz_oxide is an intentionally simple
implementation. It would be more fair to compare it to the
newer zlib-rs[1], which even beats zlib-ng (fastest
implementation in C)[2].[1]:
https://lib.rs/crates/zlib-rs[2]:
https://trifectatech.org/blog/zlib-rs-is-faster-than-c/
|
gobdovan
Have you considered exposing these optimisations through a
library so programmers can request optimisation passes and
have the compiler check the preconditions?Asking cuz I'm
preparing an article on how fast JS can get and found the
same thing, you can get in 10% of optimised C-code with
basically any code if you torture V8 enough (excepting
SIMD where there seems to be a bug in V8 where it doesn't
optimise to SIMD even when beyond obvious). Figured out I
could extract it in a lib and do it more streamlined but
not sure how well manual transforms generalise.Also, when
working on the roc-deflate, did you find recurring
transformations that could fit that model or were most
improvements specific to compression?
|
pmkary
This is kind of hacker news post and comments I like;
extreme languages on extreme performance with extreme
features, not types being added to a language ten
gizzilion times slower than a tortoise and the post making
anti-type flat-earthers getting freaked out if they have
to vaccinate next.
|
jeffbee
This seems to raise the question: is libdeflate fast? My
overall impression of libdeflate is that it produces a
similar output size to zstd but takes 40 times longer to
do it. I realize these are different algorithms of course,
but they aren't that different, both being in the Huffman
line of the LZ family. So why is libdeflate considered a
performance benchmark?
|
> antonvs
It's probably just because a zstd implementation in
Lean would be more difficult. The whole project
depends on being able to have a correctness proof for
the implementation, and implementing that for the
DEFLATE algorithm is simpler.
|
> > tkz1312
https://github.com/kim-em/lean-zstd
|
eigenblake
I'm very simple. I see Richard Feldman post. I like it.
I'll leave it to the experts as to whether this is a case
of opportunistic mutation.
|
jdw64
What are some well known programs made with Roc? And I'm
curious about the difficulty level of its syntax
|
> grayrest
There are no well known programs made with Roc. It's
been usable for writing real software since July or so
for those of us willing to deal with compiler crashes
and regular syntax/feature changes. To my knowledge
there are six people producing substantial amounts of
software in Roc. I'm using it for a speech
recognition/transcription app and the desktop
environment and apps on my eink tablet, both on my own
UI framework.
|
> prerok
Well, it has not even reached 0.1.0, so the language
is still in early development phase. But it has
interesting properties, so I would recommend
experimenting with it.
|