It's not nonsense; the point is that calling a Numpy function needs to be done from Python. You cannot pipe stdin to np.array().
645 karma · joined October 28, 2016
In the case of Unix, the question is probably "what is the canonical representation of executable code". I think the author's intent was to mostly talk about shell scripts, and not something like C code. Manipulating shell scripts via e.g. sed is, I think, pretty doable.
I'm also a bit confused why homoiconicity needs to be convenient to be real. Most people don't find shell a very convenient language in other aspects, either.
Naming everything as a function often leads to a problem of very deep visual nesting. For example, map-then-filter can be written as "filter p . map f" in Haskell, whereas in sigil-free languages you'd write a mess like (lambda (x) (filter p (map f x))) in Lisp or "lambda x: filter(p, map(f, x))" in Python.
Of course, function composition is a very simple case, but something like lenses are another less simple case where a library would be unusable without custom operators.
Saying OneAPI/SYCL is bad "because OpenCL" is the same as saying OpenCL is good "because CUDA" (since the NVIDIA implementation of OpenCL is called CUDA and uses the larger CUDA stack).
As for the FPGA/GPU code sharing, iirc FPGA vendors including Altera/Intel and Xilinx/AMD support OpenCL as well. The idea doesn't sound that crazy to me: GPU code also often uses small data types (fp16, tf32, int4), and both work with data parallelism. GPUs operate in parallel with SIMD vectors, but a compute accelerator FPGA achieves a similar thing by essentially pipelining the program. Effective pipelining requires parallelism too, since a serial FPGA program only has one stage active, similar to how a serial GPU program only has one ALU per compute unit active. As such both are mostly suitable for massively parallel programs.
I haven't used Bluefin, but don't Bluefin exceptions suffer from the same issue where it, essentially, 'infects' the program flow? For example, `fst (5, error "second")` seems like it would translate to `fst $ (5,) <$> throw e "second"`, where you would also need to pull an `e` from somewhere. More realistic, something like head would probably be quite awkward:
head e [] = throw e "head: empty list" head e (x:xs) = pure x
You now need to pass in the exception handle, and the return value is now `Eff es a` instead of `a`. This means that you cannot just use the result, so you will likely need to fill your program with monadic stuff like do-notation, <$> and <$>, complicating the program flow and likely also reducing laziness.
What is presumably talked about is that Haskell also has actual exceptions, generated by calling e.g. `error` or `undefined`.
The semantics of these are.. interesting, mostly thanks to lazy evaluation. For example, `fst (5, error "second") ` is safe to evaluate because the second half of the tuple is a thunk and does not get evaluated. Additionally, there is, to my knowledge, no way to handle exceptions in pure code, presumably due to the undefined evaluation order.
That said, I'm not sure what the alternative would be, because a function like !! (list indexing) can fail and dealing with its fallibility would be a big burden on the programmer.
If AMD were to work on SYCL tooling and, say, build a 'syclcc' next to 'hipcc' that ingested SYCL to run it on ROCm, I feel like interest in SYCL could potentially grow, since Intel is supporting it properly already and it would be actually a cross-vendor standard.
Codeplay (which is part of Intel) does provide 'plugins' to run oneAPI (SYCL) on NVIDIA and AMD hardware, which is great but is still being made, indirectly, by Intel, who in the end want to sell Intel hardware.
And with HIP, the user-facing memory model is virtually identical to CUDA to my knowledge. Converting a CUDA program to HIP, assuming no unsupported features or platform details are used, is basically just "do s/cu/hip/g".
Also, HIP wasn't around in 2014. To program an AMD GPU back then, you were probably using OpenCL, which is nicely platform independent but also arguably somewhat archaic.
It's as simple as right click it -> Activity Bar Position -> ...
But I really don't think cramming a bunch of proprietary online services like ChatGPT counts as "intentional and methodical". It comes across more like a "we need AI!!!" cry of desperation, throwing principles like privacy in the wind.
> This scheme appeared with Tremont, where it could only switch decoders at taken branch boundarie and Gracemont improves load balancing between the two decode clusters by automatically switching, instead of relying on taken branches. That helps performance in very long unrolled loops, which could get stuck on one decode cluster on Tremont. When we tested with longer loop lengths, we didn’t see any drop off in Gracemont’s instruction throughput:
- https://chipsandcheese.com/2021/12/21/gracemont-revenge-of-t...
???
Yes, roads require less 'active upkeep', an austerity government might stop funding transit but they will not close roads. However, this is more of a feature of the supposed 'independence' of car transport, not 'easy to understand'.
In addition, defunding transit would be a lot harder and weirder if it is in a form that requires actual infrastructure (metro, train, tram) rather than some stops and a schedule (bus). That's one potential reason to trust bus transit projects less.
Do keep in mind that roads aren't free after construction either; they typically require pretty significant upkeep (especially things like repaving, but also e.g. traffic signals).
Then public transport should be way cheaper than driving, as on transit you have some downtime where you can scroll through your phone, listen to some music, or perhaps even crack open your laptop if you're on a proper train. Driving requires constant attention, so you can't relax or do anything else in the meantime.
I grew up in a region with fairly mediocre transit, but because the living environment is not hostile most things can easily be done by bike unless you need to go to another city. Hell, I biked 8km to school, and while somewhat time consuming it was quite literally free exercise.
When I went to uni, before moving to that city I relied on transit. Because of the low density in the region, trains are only half-hourly (which is by far the most sucky part) and it's on single-track rails so every train stops at all stations. However during rush hour it's still time-competitive with cars, and transfers are generally pretty good because those are the reason transit works in that region at all.
Something like "you need a car to be able to get to (store)" that's mentioned in another comment would be literally unthinkable here. You can get practically anywhere with a bike and a transit card.
The intercity trains, when in a maximum length 6+6 car configuration of 2-floor trains, can carry over 1200 (sitting!) passengers. That's as much as a single lane of road can carry in half an hour with average car occupancy (low). So running such a train every 15 minutes should give a similar capacity to a free-flowing road with 2 lanes, while needing less room for infrastructure. Plus people mostly go to the station by foot, bike or bus rather than car, which is also nice capacity-wise and pollution-wise.
If you want to step on it, leave the city. Most non-access roads in non-built-up areas are 50mph, and more for motorways. Some major urban thoroughfares are also 45mph.
Which ones? I'm aware of AMD/ATi Terascale using VLIW, but I'm pretty sure that architecture also used SIMD (requiring the use of both VLIW and large 'waves' to achieve maximum occupancy).
And running shaders on CPU is, in essence, a similar programming model to ISPC. When you run OpenCL on a CPU I am quite certain that the runtime pretends each lane is a program instance, same as ISPC.