PeCaN · HackerTrans

PeCaN

no profile record

投稿

BOLT: A Facebook tool to optimize binaries

github.com

1 ポイント投稿者 PeCaN8 年前0 コメント

ArcaOS 5.0 – A Modern OS/2 Release – Is Now Available

arcanoae.com

1 ポイント投稿者 PeCaN9 年前0 コメント

A MIDI-Based Programming Language

velato.net

2 ポイント投稿者 PeCaN10 年前1 コメント

MonetDB – Column-store database

monetdb.org

113 ポイント投稿者 PeCaN10 年前41 コメント

United States V. Approximately 64,695 Pounds of Shark Fins

en.wikipedia.org

2 ポイント投稿者 PeCaN10 年前0 コメント

The Future as of 2003 – Web Services and WinFS

youtube.com

2 ポイント投稿者 PeCaN10 年前0 コメント

Things That Turbo Pascal Is Smaller Than (2011)

prog21.dadgum.com

18 ポイント投稿者 PeCaN10 年前2 コメント

A Virtual Machine for Interpreting Programs in Static Single Assignment Form [pdf]

cs.utsa.edu

3 ポイント投稿者 PeCaN10 年前0 コメント

Taylor: Swift on bare metal

github.com

2 ポイント投稿者 PeCaN10 年前0 コメント

コメント

6 年前議論

To be honest I don't really see people who don't want to learn APL being that interested in putting in the effort to completely upend how they think about programming and algorithms in order to use other array languages, regardless of syntax. (After all this is by far the hardest part of learning APL, the symbols are easy enough and easy to look up anyway.)

map is general in kind of the wrong way. You could after all add a #map method to Object for scalars and make a Matrix class that also implements it and then just call map everywhere. However you still run into the problem, mentioned in the video, that it doesn't easily generalize to x + y where both x and y are arrays; you have to use zip or map2 or something (and now you still have to figure out how to do vector + matrix) and yes you can kind of do explicit "array programming" in Ruby if for some reason you're really compelled to do that but it will look awful. And that's just what array languages do for you implicitly. As a paradigm there's a bit more too it than "just call map everywhere"—there's still all the functions for expressing algorithms as computations on arrays.

6 年前議論

If you watch the video it looks like their proposed syntax is not APL-like but closer to mainstream languages.

I'm honestly not sure if this is a good thing or not. You said "easier" syntax than APL but APL is honestly a very easy syntax for working with arrays. That's a significant part of the advantage of APL, it makes it very easy to come up with, talk about, and maintain array algorithms.

Matlab and Julia and other languages aimed at scientific computing have some array language-like traits but lack a lot of the functions that make APL more generally applicable. And .map is all wrong; it's extra noise and it doesn't generalize down to scalars or up to matrices—the defining feature of array languages is that operations are implicitly polymorphic over the rank of the input.

6 年前議論

I've been working on something like this on and off for the past 4 years or so, although with something more like generators than streams.

I think it's a very, very promising idea (I admit to heavily being biased towards anything APL-influenced) although surprisingly difficult to get right. Gilad Bracha is obviously way smarter than me so I'm definitely curious where he goes with this.

One additional idea that I keep trying to make work is integrating variations of (constraint) logic programming and treating solutions to a predicate as a generator or stream that operations can be lifted to rank-polymorphically. As a simple example a range function could be defined and used like (imaginary illustrative syntax)

    range(n,m,x) :- n <= x, x <= m
    
    primesUpto(n) = range(2,n,r),               # create a generator containing all solutions wrt r
      mask(not(contains(outerProduct(*, r, r), r)), r)  # as in the video

I've never really gotten this to work nicely and it always feels like there's a sort of separation between the logic world and the array world. However this feels incredibly powerful, especially as part of some sort of database, so I keep returning to it even though I'm not really sure it goes anywhere super useful in the end.

6 年前議論

it's not so much that gcc does anything specific so much as LLVM is just really really inefficient—they don't track compilation time at all so it's easy for releases to regress, half the stuff in there is academics implementing their PhD thesis aiming for algorithmic accuracy with little regard for efficiency, and LLVM's design itself is somewhat inefficient (multiple IRs, lots and lots of pointers in IR representation, etc)

that said this makes it an excellent testbed but compilation time will keep getting slower every release until they start caring about it

6 年前議論

that's just because gcc has certain optimization passes that can't be disabled

(that said gcc -O0 is still absolutely nothing like what a human would write)

6 年前議論

- it takes some die space sure but no x86 processors are actually limited by instruction decoding (except, iirc, the first generation xeon phi in some cases)

- huge pages don't exactly require weird OS hoops although i agree the 4kb→2mb→1gb page sizes are inconvenient

6 年前議論

All the Intel CPUs with RDRAND, although I guess that's not exactly hidden anymore.

6 年前議論

I sort of wonder if this approach to JITing is worth it over just writing a faster interpreter. This is basically like what V8's baseline JIT used to be and they switched to an interpreter without that much of a performance hit (and there's still a lot of potential optimizations for their interpreter). LuaJIT 1's compiler was similar, although somewhat more elaborate, and yet still routinely beaten by LuaJIT 2's interpreter (to be fair LuaJIT 2's interpreter is an insane feat of engineering).

6 年前議論

That's fair. It's definitely not a killer, (or even in my opinion the worst thing about RISC-V,) just another one of these random little annoyances that I'm not really sure why RISC-V doesn't include.

6 年前議論

It's not like someone is proposing some crazy new instruction to do vector math on binary coded decimals while also calculating CRC32 values as a byproduct. It's conditional move. Every ISA I can think of has that.

6 年前議論

>[She] complains Risc-V need 4 instructions to do what x86_64 and arm does in two, but... it says Risc-V.

So… what, it should take 5 instructions?

Executing more instructions for a (really) common operation doesn't mean an ISA is somehow better designed or "more RISC", it means it executes more instructions.

>And x86_64 CISC instructions devolve to a pile of microcode anyway.

Some people seem to have this impression that like every x86 instruction is implemented in microcode (very, very few of them are) and even charitably interpreting that as "decodes to multiple uops" (which is completely different) is still not right. The mov in the example is 1 uop.

6 年前議論

I'm not sure about this "RISC way" stuff. From a uarch standpoint the RISC vs CISC distinction is moot and from an ISA standpoint the only real quantifiable difference seems to be being a load-store architecture.

ISAs without conditional moves tend to have predicated instructions which are functionally the same thing. I'm not actually aware of any traditionally RISC architectures that have neither conditional moves or predicated instructions. While ARMv7 removed predicated instructions as a general feature ARMv8 gained a few "conditional data processing" instructions (e.g. CSEL is basically cmov), so clearly at least ARM thinks there's a benefit even with modern branch predictors.

Conditional instructions are really, really handy when you need them. It's an escape hatch for when you have an unbiased branch and need to turn control flow into data flow.

6 年前議論

ARM has it. DEC Alpha had it (before x86, even).

I get that there are a lot of narrow-use instructions but popcount is a pretty well-known and common operation.

6 年前議論

popcount is extremely useful in a lot of algorithms, from RSA to chess engines to sparse arrays and tries

it's honestly pretty baffling that RISC-V doesnt have it (perils of design-by-academia)

6 年前議論

Not that. https://en.wikipedia.org/wiki/Threaded_code

It's an interpreter implementation technique.

6 年前議論

Ironically enough I feel like IBM is actually an example of a giant company that, against all odds, is somehow still innovating, at least with its POWER CPUs. They're doing really interesting and open-ended things like CAPI and the upcoming Open Memory Interface.

6 年前議論

how are europoors so consistently butthurt about fucking units of temperature

6 年前議論

I considered multiple selections a bit of a gimmick in sublime text and various emacs/vim extensions but the way it works in kakoune feels completely different.

Think about vim (and kakoune) as basically a highly interactive language for editing text. At least at a conceptual level something like diw is basically a function (d) applied to data (iw). Vim is completely scalar. The type of all the functions is more or less something like string → string. Kakoune is the APL of text editors. Multiple selections are an array of strings to operate on. It automatically maps the function (editor commands) over every selection. I find this extremely attractive and powerful.

At least for me kakoune blows all other editors out of the water. It really is quite good.

6 年前議論

Humans were actually incapable of abstract thought until hacker news invented it.

6 年前議論

Probably not, since it's optimized for scientific workloads (being designed specifically for the K computer replacement) (so it doesn't have texture units, ROPs, etc; you'd have to do too much in software to make it actually render things). However I think the overall design is really good and has enormous potential, if not for graphics at the very least for ML.

The vector architectures with extremely high memory bandwidth coming out of Japan recently (NEC SX-Aurora Tsubasa, Fujitsu A64FX) are pretty fascinating.