
How to accelerate a program using hardware - conorpp
https://conorpp.com/blog/how-to-accelerate-a--program-with-hardware/
======
nickpsecurity
Nice simple introduction. Would be interesting for someone here with access to
HLS tools, esp C to verilog stuff, to tell us what speedup they get straight-
up using the C code. As in, very little input past what the HLS tools come up
with.

------
rmohanx
PFC. Rough idea how this might compare to a pathologically and expertly
tweaked assembly version?

~~~
nickpsecurity
I guarantee it would smoke it by similarly ridiculous numbers. Assembler will
inherently be doing ops sequentially while also waiting on memory accesses in
between them where not cached. An expected speed up might factor in the clock
difference between it and yours plus number of cores. Yet, you're not going to
get the kind of parallelism and simple operation you have with custom HW. It's
the lasting drawback of general-purpose CPU's.

And why Intel is buying Altera. Stuff like this article will get easier and
with even bigger speedups in the near future. Just wait. :)

~~~
p1esk
It's more interesting to see what could be done with a GPU.

Also, I wonder if we could bypass the shared main memory, and to turn the
pixels on and off directly (by hacking the display driver or whatever).

~~~
nomel
> Also, I wonder if we could bypass the shared main memory, and to turn the
> pixels on and off directly

The pixels exist in a shared memory, do they not?

~~~
p1esk
Pixels are mapped to memory locations, but they don't have to be, if you can
access the map directly. I don't exactly know what I'm talking about here,
just a thought.

~~~
conorpp
What would be the difference between writing to shared hardware pixels over a
shared memory performance wise?

I mean, pixels are just like a memory except that they glow. They hold their
value and can be writen a new value in sync with a clock (which is normally 60
Hz for most monitors which is MUCH slower then on chip memory). There could be
no performance benefit.

