Pipelining (Instruction-Level Parallelism)
https://en.algorithmica.org/hpc/pipelining/

In order for a CPU to execute any instruction, it needs to follow a few steps:
Fetch machine code from memory
Decode the code and recognize instructions
Execute the instructions where some may do memory operations
Write the results to memory

Notice after an instruction is fetched, CPU can start to process the next one without waiting for it to complete. Modern CPUs take advantage of this and perform a "free" (since we are not using an extra core) parallelism. This is called Pipelining

#cpu #pipelining #parallesim

A simple vim trick that can come in handy. If you need to access output of one/multiple command(s), you can use :redir, Simply use it like below:

:redir >> output.txt

And execute your desired commands. After you are done, you can use

:redir END

to write the outputs to output.txt.

Example:

:redir >> output.txt
:echo "hello there"
:redir END

#vim

Regarding to pipe-lining, they don't always result in optimization. There are times when you might run into obstacles called Pipeline Hazards.
There are three types of pipeline hazards:

Structural Hazard: When two or more instructions need the same unit of CPU
Data Hazard: An instruction needs to wait for a previous operation to be completed
Control Hazard: CPU can’t tell which instructions it needs to execute next

The third one probably got your attention. How could CPU not know which instruction to execute next? Imagine a simple If statement. When CPU reaches this type of branching, It cannot choose future instructions with 100% certainty. That's why there a set of tricks to remove branches from your program as much as possible called Branchless-Programming.

It's worth noting that compilers do a set of optimizations in regard of removing branches as well. So knowing how your compiler acts is essential to how you optimize your code.

#CPU #Pipelining #Branchless_Programming.

Some of you vim users might miss how useful quick-fix list can be. An example can be mixing it with !make. Make command, when used after !compiler <name>, tries to compile your project then writes the resulting errors into a quick-fix list. It also supports a lot of compilers by default (like tsc).
This can be achieved like below:

!compiler tsc
!make
!copen

So if you are about to change a piece of code that probably triggers a lot of errors in your project, this is the way to get it on a quick-fix or location list. For more information on quick fix list:

!help quickfix

#vim

I wrote a simple C implementation of LZW compression scheme.
https://github.com/Keivan-sf/lzw/

LZW is a fast compression scheme which is behind .Z files; for example:

filename.tar.Z

These files were usually compressed and uncompressed via linux compress program

#compression #lzw

Purplesyringa (github) decided to compress her blog posts via webp and decode them in the browser using native APIs and it actually works!

https://purplesyringa.moe/blog/webp-the-webpage-compression-format/

This is very interesting since the image decompression utilities are already present in the browser so there is no overhead/extra code for decoding the compressed html page.

#compression

My average youtube feed

Sudo program is still receiving updates. Latest version just dropped last week
https://github.com/sudo-project/sudo

Todd Miller, who has been maintaining sudo for the past 30+ years

SQLite is not a toy database

https://antonz.org/sqlite-is-not-a-toy-database

Personally, I find sqlite to be very convenient. Being simple and serverless, supported by your favorite ORM and easy to setup just contributes to this quality.

#sql #sqlite

in-terminal shop to order coffee!

ssh terminal.shop

The idea of serving a TUI on ssh connection is just pretty cool

I've just implemented decompression for this program as well. This is still compatible with linux compress program except for reset characters which are to be implemented later on.

Repo:
https://github.com/Keivan-sf/lzw/

#compression #lzw

I have been trying to understand signal compression for the past few weeks. It's amazing how simple image/audio compression works. Both images and audios can be considered as signals. Take audio for example; an analog audio signal can be represented as below

Notice that at any given point in time we have a certain amplitude, plus there are infinite points of time. This signal can be captured via a microphone and stored in something like a gramophone record. But we want to store them digitally right? We no longer have gramophones. Or in other words, we need this signal to be discrete rather than continues in order for us to store it in a computer. So we have to sample this signal at a frequency. This raises a few questions:
- At what frequency we should sample our continues signal (sample rate)
- How many bits we should use for storing each sample, or rather what is the amplitude range we are willing to cover (bit depth)
p.s: Bit-rate is basically sample rate multiplied by bit depth

For the first question, the answer lies in Nyquist–Shannon sampling theorem. Which states that to reconstruct a signal via samples, we have to at least sample at double the frequency of the original signal. This makes a lot of sense if we just look at visualization:

You can see if we sample double the frequency of our audio signal we have a chance for a good reconstruction later on. Note that this is the most optimistic view. For example in the pictures above we started sampling with a little bit delay to capture the peak of our signal. In reality this is not feasible. If we started sampling at 0s, we would've ended up with a straight line, even if we sampled double the frequency.
So its fair to say that most signals will require even more than double for a good reconstruction