waltpad

Ooops, I didn't mean Xeon PHI, I meant an older design with many small x86 cores.

Xeon PHI on the other hand was the first host of AVX-512 instruction set. Sorry.

The programming model is not very flexible at the lowest level: one has to create all the software infrastructure to communicate with the GPU (which boils down to sending commands and receiving response). There are languages (like futhark, julia, or even python), which handle all that boilerplate transparently.

The main problem is, afaik, that there is not enough control about where the code will run in these languages. At some point, one will want to describe all the algorithms using a single language, and somehow describe how the workload will have to be distributed across all the processors, or at least that's what I've been thinking about for a while. Once you have that level of control, the need for a versatile CPU is less clear. Note that nowadays people seems happy with hybrid solutions where the code is scattered across several languages (eg, one for the main program and one for the shaders, or for the client side UI), so my position is maybe not very strong.

HW-wise, is it possible that integrated GPUs are the first steps toward an architecture where CPU and GPU have better interconnections (ie, larger communication bandwidth and smaller latency) to the point where SIMD becomes moot? There is also the SWAR approach, where one doesn't rely on intrinsic SIMD instructions, but instead emulate them (though it's probably not very realistic for floating point computation).

Some other ideas:

- Apple has this neural engine in their latest chips, which is basically dedicated HW for neural networks

- In the wild, people are getting more and more interested in building their custom ASICs to cut software's middle-man cost: for them, the CPU solution is not good enough

- Intel recently introduced a new matrix ops extension in their CPUs: maybe at some point they'll introduce full GPU capabilities directly baked in the CPU? I am a little worried about the resulting ISA.

Anyway, I am not an HW engineer, nor a very good software one. I only have a limited view of the difficulties in writing good, CPU or GPU efficient code. My first post was prompted by remembering the first "large scale" multicores CPUs 15 years ago (specifically the Ultrasparc T1) which wheren't SIMD heavy. The direction naturally shifted as progress was made on SIMD to try to compete with GPUs, when it seems to me that originally CPUs and GPUs were complementary.

I tend to support modular solutions, but I don't know how costly that would be in term of efficiency at the HW level.

The point I was trying to make is that if you have to rely on runtime type information, you might as well use sum types in a more strongly typed language, where the scope of the code gets limited to the type itself.

With "duck typing", you need to have an extra test for types which your code is not supposed to work with, whereas with sum types, the type checker will help you verify that it cannot happen.

That being said, there are situations which a strong type system will not be able to model.

Anyway, at the end of the day, what matters is that you (and your coworkers) feel comfortable with your code. I know by experience that it's not always the case.

I think another interesting question is, how would you handle the return value of such function in your code?

You would have to either:

- test for the type of that value in order to handle it properly,

- rely of the implicit cast rules of JS, which wouldn't be very useful here I suppose

As it has been said by others, in Ocaml (as well as in many other strongly typed languages) you can use a sum type to solve that problem.

Edit: In some languages, there is also the concept of "intersection types" which, if I understand correctly, let one also handle that sort of situation. The corresponding Wikipedia entry [1] gives a list of languages supporting that concept, and provides examples.

[1] https://en.wikipedia.org/wiki/Intersection_type

Disclaimer: I am not a HW designer, I could very well be wrong.

It is true that there are tasks where threading matters, but still require a CPU rather than a GPU. I wonder however if these tasks do need full SSE/AVX etc. Couldn't these extensions be removed of the CPU cores and instead have the necessary work performed by the GPU?

It would be interesting to produce statistics on how much these extensions are used in these scenario. Imagine how much space and complexity could be saved on a CPU die by making stripped down versions. That space could in turn be used for more cores!

I read a little about the Xeon PHI cpus, which iirc, is a multicore CPU with a very small ISA, but I wonder why x86 makers aren't trying to go in that direction: isn't there plenty of dedicated workloads which would happily run on these (eg, web servers), or is this just a (too) simplistic view?

t's really hard to get away from getting data in JSON these days. It's ubiquitous.

Yes, I agree with that. It's a neat format if you have small pieces of information to move around, and it's very easy to read for humans, but for large enough data, wouldn't it turn into a bottle neck?

If I would go binary it would probably be something like protobuf, not ad-hoc. Ad-hoc has issues with maintenance, interop, and tooling.

Indeed, there's always these dimensions to take into consideration, as well as evolution. The main issue is to find a library/format which is well supported across all sort of languages, and JSON has that. I don't know if there are many binary formats with the same level of support.

I suggested ad-hoc because the format seemed simple enough to be mmapped directly, or something equivalent (not sure how scripting languages would do in that case).

100MB of doubles encoded as JSON.

That sounds like a very bad use case for JSON. I would be surprised if your program wasn't more efficient with an ad-hoc binary format for that piece of data.

fails at logic more than at poetry

This is purely subjective.

Your expectations in Poetry might be different from those of other people or even specialists. I am not particularly good in that domain, but I don't really like the results shown sometimes.

Sadly, AFAIK, BLAS hasn't been updated to use generics. It would be so nice to have support for integer vector/matrix operations in there (not that it would require generics to have that, but it could be easier to implement integer support with it, though I suspect that for efficiency reason it might not be used in the end).

If you have a look at the different fortran implementations of BLAS gemm (matrix multiplication), you'll see that the transposed matrix cases are treated specifically. In fact, IIRC, the gemm function has flags to indicate for each matrix if it is transposed.

Oh, I understand. I suppose it makes sense, if for instance one needs to store a bunch of parameters somewhere, it might as well be a JSON file.

The difference is that your DB is the FS, and each JSON file is an individual record. You're not storing each table in a single JSON document.

Maybe because it was tempting: JSON is fairly easy to handle, very portable, and when you look at a JSON document, it's straightforward to think about querying it, and thus DB, although JSON is structured, and DBs are relational.

I think that, oddly enough, the point of that project is to use the JSON format as the DB storage format, not as an export option. Just from the look of it (I don't know either projects), LokiJS will very likely be always faster.

That's a very strange idea: JSON is basically structured data, like XML, it's nice for documents with deeply nested structures.

The main issue is that contrarily to a DB, any modification will shift everything after it, so any indexing will have to be corrected. I suppose that if the document is not stored as is, but instead broken up in pages (filesystems are likely doing that already, so piggy backing on that could help), then indexing could be improved, but then storage starts to look like a regular DB, rather than JSON.

Interesting nonetheless, time will tell.

I wonder how the clipboard API could be fixed.

I suppose that the current scheme is that apps are monitoring paste events, and when it happens have a look at the clipboard for copied data.

Perhaps the clipboard shouldn't be visible at all, and only when the user decides to paste content should the targeted app receive a "paste" message with the copied data (or perhaps some more complicated selection mechanism with a list of recent copies à la emacs). This would essentially merge the 2 steps process outlined above into a single operation.

It's probably more complicated than that though.

Well, if copies may be borrowed, as it is the case in Rust, I suppose that a type-linear function, as I called it, doesn't have to be computationally linear. The `mult` example we discussed could not be applied twice to the same value, unless it is declared as borrowing its parameters from the caller.

Elaborating on this, with a function signature like the following:

    fn mult(x : Vec<f32>, y : Vec<f32>) -> Vec<f32> {
       // matrix product implementation 
    }

    mult(a,a)

Conversely, with the following signature:

    fn mult(x : &Vec<f32>, y : &Vec<f32>) -> Vec<f32> {
       // ...
    }

    mult(&a,&a)

Now, nothing prevents one to implement the function square, based on the second version of mult:

    fn square(x : Vec<f32>) -> Vec<f32> {
        return mult(&x,&x)
    }

Clearly your original question was spot on.

I don't think these technologies are related: Java Generics is based on subtyping, however Haskell doesn't support subtyping (afaik).

Seriously though, the Opera web browser has this functionality built in, but it's a "toggle" back to top, by just clicking on the tab title.

It's very useful on web sites like HN, when you don't want to lose where you are in the thread, yet need to go back to the top to have a second look at the topic for instance.

Sorry, I got confused on the meaning linear.

As explained in the other answer, it's possible to implement the power function which is "type-linear" on each argument, but that function will not otherwise be linear (ie, the mathematical meaning of linear) on its arguments.

In Rust for instance, affine types are used to restrict usage of values linearly, which means that a value passed as argument will be by default moved from caller to callee: The value will not be available anymore to the caller. This has some consequences for instance for binary operators on values which require special care when moved (structures, arrays): with the restriction explained above, a value cannot be passed more than once to a function, and thus doing something like 'mult(x,x)' (where x is eg. a matrix) will not work because x appears twice, but may only be moved once. The solution offered by the language, called "borrowing" is to use references for the arguments: a borrowed value is no longer being moved; instead, it remains in the scope of the caller, and the callee only receives a reference. References may be created and duplicated, allowing multiple uses of the same piece of data.

What's the provided GPU solution for ARM based machines? Do Apple SoCs contain a GPU?

no.

Probably not much.

I hope so: this article assumes that for normal citizens, monitoring seems to be a problem, so it's only natural to expect the police forces to get upset for the same reasons. That being said, it's possible that they're already used to be monitored constantly.

That only addresses the one gripe I brought up as an example though, and not the general pattern. For instance another issue I've run into is this automagical hacks that parse fstab crypttab etc and make units at boot time, while not actually supporting all the customary options of those files.

Maybe the long term plan is to have these files dropped and replaced with something more systemd like?

we're left with a hodgepodge of the old and new systems.

Same argument: if the long term goal is to completely overhawl the system, then at any point before that goal is reached there has to be old devices still in place.

That being said, I don't know much about systemd, not about the long term goals of systemd authors. I think that Poettering language of choice is C, so this explains that, but there's always room for other solutions in the FOSS world.

How much good grace would be earned if the military surveillance was used to prosecute police brutality and misuse of authority in addition to arson and looting?

Nothing in the article says that they don't monitor police activity. I wonder what would be the police reaction if this were happening and made public.

I don't get why this comment is being downvoted.

It probably tells that you also hit the paywall. Those who downvoted probably didn't, perhaps because their setup doesn't trigger it by default, or because they searched by themselves how to avoid it.

I personally didn't see any paywall when accessing the site directly (ie, without a VPN).

Or applying it if that value is a function. I believe the broader definition would be that it has to appear in an "evaluated" term.

The problem is the design decision of using a simplistic data model that fails in that spectacular and unintuitive way.

I don't see how it could be made intuitive. How would you design it?

Or they didn't want to end up producing code with noticeable fluctuations in efficiency, as it is described later in the article: sometimes, having consistent (read predictable) computation times is better.

Maybe it wouldn't be possible to have several processes working in parallel, but instead a single process with 5 cores available for threads? Consider the PS3 arch for instance: it had 7 cores, 1 for management and the rest for computing. Could it be the way Intel envision its future lines of products?