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

KlongPy: High-Performance Array Programming in Python

github.com

Post reply on HN
Print view View original

51–60 of 90 posts

Re: KlongPy: High-Performance Array Programming in Python

#51

Post by faizshah »

ramses0 wrote: post #46
faizshah wrote: post #39

I’ve tried several times to give J/k/Q/kdb a chance but I haven’t really found a convincing example why this approach is better than say SQL or say numpy/jax etc. The syntax has the same problem as perl in that you have to learn too many symbols that are hard to look up. And this combined with the tacit style makes it difficult to parse what the code is doing. I think ruby went in the radically opposite direction in…

There was a step-change improvement for me when I tried expressing some JS patterns via `underscore.js` instead of procedurally: eg: http://underscorejs.org/#each Thinking of something as `each | map | filter | sum` is waaay less buggy than writing bespoke procedural code to do the same thing. No doubt there is a "cost" to it as well, but the _abstraction_ is valuable. Now, if there were a "compiler" which could opti…

I 100% agree, I think the functional features that have been added across all the popular languages (map, reduce, fold etc.) has been a positive. Nothing demonstrates it better (imo) than purrr in R: https://github.com/rstudio/cheatsheets/blob/main/purrr.pdf

I also think there is some merit to “high syntactical density” clearly if you can see the entire code in one place instead of having to navigate through many files or sections that’s beneficial. (Heavily discussed in the last big HN thread: https://news.ycombinator.com/item?id=38981639)

I also think JQ has proven the merit of tacit functional languages in that you can concisely write arbitrary transforms/queries on json that can be more expressive than SQL (many SQL engines have added JSONPath anyway). And I also think postfix is great for processing pipelines.

But I am not totally convinced in the approach of APL/J/Q/KDB for the combination of terse style + prefix + tacit because it makes the code so difficult to read. I think if you took an approach similar to JQ where instead of relying on symbols operators were just human readable words it would be easier to get us half way there to trying out the verb, adverbs etc. approach of the APL family. The problem with making it human readable text is that you lose the conciseness which is part of the draw of the APL family as they want to have a high syntax density and analogous code to mathematical expressions.

Re: KlongPy: High-Performance Array Programming in Python

#52

Post by abrudz »

cturner wrote: post #30

I would love something like duolingo, but for an array language. Not a steady series of challenging puzzles like leetcode sites, Rather, a series of questions with high repetition, somewhat like flash cards, easy to drop into for a few minutes.

See https://github.com/Isaac-Flath/anki and https://github.com/aeamaea/APL_Anki_Decks

Re: KlongPy: High-Performance Array Programming in Python

#53

Post by abrudz »

amarcheschi wrote: post #19

I'm gonna be the one who asks the dumb question, but someone has to do it: why are expressions evaluated from right to left?

Think "normal" call syntax like

  foo(bar(baz(42)))
and then remove the superfluous parens

  foo bar baz 42
The expression is evaluated from right to left.

Now, let's make two of the functions into object members:

  A.foo(bar(B.baz(42)))
Remove the parens, extracting the methods from their objects, instead feeding each object as a left argument to its former member function:

  A foo bar B baz 42
This is normal APL-style call syntax; right-to-left if you want.

Re: KlongPy: High-Performance Array Programming in Python

#54

Post by bunderbunder »

dzaima wrote: post #49
CyberDildonics wrote: post #40

Earlier quoted context omitted.

I'm not exactly sure what this means, but the bandwidth to the level 3 cache isn't actually more than memory. If you only have a few megabytes to work with, it's a lot less likely performance is going to matter anyway, and if it does you would still want to do multiple operations on each array item if possible, because if you put a few more lines in a loop you're talking about registers at that point, not cache.

L3 cache bandwidth is often more than main memory; most systems at https://old.chipsandcheese.com/memory-bandwidth-data/ give at least a ~2x difference from whatever sample I clicked.

And on a recent generation Xeon, your mid-level data cache can total up to 64MB, depending on model. That's maybe the more interesting one? L3 cache is shared among cores, so access to it can be more heavily impacted by memory concurrency concerns and not just pure bandwidth concerns. Meaning there's potentially a strong incentive to keep your task size below 2MB per core.

Re: KlongPy: High-Performance Array Programming in Python

#55

Post by behnamoh »

juliangoldsmith wrote: post #35
behnamoh wrote: post #22

What are some real-world practical applications of array programming? Because as far as I know, APL did not catch on, and its subsequent versions like J and K and BNQ also did not become useful in industry. Maybe there's something I'm missing. Why would you want to do array programming in Python? What are the advantages over regular Python programming?

The array languages aren't super popular because of the sharp learning curve. They're a lot different than most other languages, and they have a lot of operators that simply don't exist in something like C++. A few years ago there was an article about K's use in high-frequency trading. I'm not sure about usage of APL and J, though. BQN is still fairly new, so it will take a while to see much production usage. If you'…

> including taking a lot of terminology (rank, etc.).

AFAIK that's a linear algebra term for matrices, not something array programming or Pytorch or TF invented.

Re: KlongPy: High-Performance Array Programming in Python

#56

Post by ssfrr »

behnamoh wrote: post #55
juliangoldsmith wrote: post #35

Earlier quoted context omitted.

The array languages aren't super popular because of the sharp learning curve. They're a lot different than most other languages, and they have a lot of operators that simply don't exist in something like C++. A few years ago there was an article about K's use in high-frequency trading. I'm not sure about usage of APL and J, though. BQN is still fairly new, so it will take a while to see much production usage. If you'…

> including taking a lot of terminology (rank, etc.). AFAIK that's a linear algebra term for matrices, not something array programming or Pytorch or TF invented.

it's an unfortunate terminology collision.

- array languages: rank is the dimensionality of an array, i.e. a vector is rank-1, a matrix is rank-2, a N-D array is rank-N

- linear algebra: rank is the number of linearly-independent columns (and also rows)

So for example, if you have a 5x5 matrix where 4 of the columns are linearly independent, it would be rank-4 in the linear algebra sense, and rank-2 in the array language sense.

I guess (though I've never really thought of it before) that you could say that the array-language definition is the rank (in the linear algebra sense) of the index space. Not sure if that's intentional.

Re: KlongPy: High-Performance Array Programming in Python

#57

Post by RyanHamilton »

faizshah wrote: post #39

I’ve tried several times to give J/k/Q/kdb a chance but I haven’t really found a convincing example why this approach is better than say SQL or say numpy/jax etc. The syntax has the same problem as perl in that you have to learn too many symbols that are hard to look up. And this combined with the tacit style makes it difficult to parse what the code is doing. I think ruby went in the radically opposite direction in…

https://www.timestored.com/b/kdb-qsql-query-vs-sql/ How many database tables have a date time column and a natural ordering? Most the data I look at. Which makes it crazy that sql is based on unordered sets.

Re: KlongPy: High-Performance Array Programming in Python

#58

Post by faizshah »

RyanHamilton wrote: post #57
faizshah wrote: post #39

I’ve tried several times to give J/k/Q/kdb a chance but I haven’t really found a convincing example why this approach is better than say SQL or say numpy/jax etc. The syntax has the same problem as perl in that you have to learn too many symbols that are hard to look up. And this combined with the tacit style makes it difficult to parse what the code is doing. I think ruby went in the radically opposite direction in…

https://www.timestored.com/b/kdb-qsql-query-vs-sql/ How many database tables have a date time column and a natural ordering? Most the data I look at. Which makes it crazy that sql is based on unordered sets.

Thanks for the link I think this is a really interesting example:

> In qSQL this is: aj[`sym`time; t; q], which means perform an asof-join on t, looking up the nearest match from table q based on the sym and time column.

> In standard SQL, again you’ll have difficulty: sql nearest date, sql closest date even just the closest lesser date isn’t elegant. One solution would be:

> WITH cte AS (SELECT t.sym, t.time, q.bid, ROW_NUMBER() OVER (PARTITION BY t.ID, t.time ORDER BY ABS(DATEDIFF(dd, t.time, p.time))) AS rowNum FROM t LEFT JOIN q ON t.sym = q.sym) SELECT sym,time,bid FROM cte WHERE rowNum = 1

> It’s worth pointing out this is one of the queries that is typically extremely slow (minutes) on row-oriented databases compared to column-oriented databases (at most a few seconds).

This is a really nice example but I think it’s more about this as of join being a really useful operation, it appears both pandas https://pandas.pydata.org/docs/reference/api/pandas.merge_as... And duckdb https://duckdb.org/docs/guides/sql_features/asof_join.html

Pandas:

> pd.merge_asof(t, q, on='time', by='sym', direction='backward')

Duckdb:

> SELECT t.sym, t.time, q.value FROM t ASOF JOIN q ON t.sym = q.sym AND t.time >= q.time;

So it seems more like this is benefitting from a useful feature of time series databases rather than the features of an APL-family language.

Personally I find the pandas syntax to be the most straightforward here.

Re: KlongPy: High-Performance Array Programming in Python

#59

Post by CyberDildonics »

bunderbunder wrote: post #54
dzaima wrote: post #49

Earlier quoted context omitted.

L3 cache bandwidth is often more than main memory; most systems at https://old.chipsandcheese.com/memory-bandwidth-data/ give at least a ~2x difference from whatever sample I clicked.

And on a recent generation Xeon, your mid-level data cache can total up to 64MB, depending on model. That's maybe the more interesting one? L3 cache is shared among cores, so access to it can be more heavily impacted by memory concurrency concerns and not just pure bandwidth concerns. Meaning there's potentially a strong incentive to keep your task size below 2MB per core.

What are doing that is computationally intensive and are using python and a CPU with 64MB of cache for, but is under 64 MB total? How do you know you aren't losing performance by doing single operations on each array in python?

Re: KlongPy: High-Performance Array Programming in Python

#60

Post by bunderbunder »

CyberDildonics wrote: post #59
bunderbunder wrote: post #54

Earlier quoted context omitted.

And on a recent generation Xeon, your mid-level data cache can total up to 64MB, depending on model. That's maybe the more interesting one? L3 cache is shared among cores, so access to it can be more heavily impacted by memory concurrency concerns and not just pure bandwidth concerns. Meaning there's potentially a strong incentive to keep your task size below 2MB per core.

What are doing that is computationally intensive and are using python and a CPU with 64MB of cache for, but is under 64 MB total? How do you know you aren't losing performance by doing single operations on each array in python?

Model training and inference, for example. Despite the hype, there's actually a lot of data science work that uses modestly-sized sets of structured data and doesn't really need a billion parameter deep learning model. And even when you're running inference on larger datasets it's often fine to just use mini batches.

I don't really think of it as a "losing" performance problem. It's all about tradeoffs. SIMD tooling often offers an easier programming model than SPMD tooling, and spending an extra 60 minutes of development time to save myself 60 seconds of run time is generally not a worthwhile trade in my problem space. Especially if I also need to run it on more expensive compute instances to realize that speedup.

Post reply on HN