<h2 id="computers-and-energy">Computers and energy</h2>
Computers are general-purpose hardware — therefore they are not the most efficient way to perform certain tasks. By definition, using FPGAs or building specific hardware for a given operation will almost always be more efficient than running code for that operation on a general-purpose CPU.
<h2 id="how-to-measure-how-much-energy-a-programming-language-consumes">How to measure how much energy a programming language consumes?</h2>
Well, in the attempt to measure it, researchers from the Universidade do Minho wrote this <a target="_blank" rel="noopener" href="https://repositorium.sdum.uminho.pt/bitstream/1822/69044/1/paper.pdf">article</a>. 
To summarize it, they basically run lot&#39;s of different algorithms in various programming language. And of course, I really encourage you to read the <a target="_blank" rel="noopener" href="https://repositorium.sdum.uminho.pt/bitstream/1822/69044/1/paper.pdf">article</a> and see the actual methodology.
Here is what they found:
<img src="/images/ple.png" alt="image">
I saw a lot of people talking about this - awesome - research, which is pretty cool. But they were using it to show that some programming languages are greener than others, which is just wrong.
I&#39;ve seen a lot of people citing this — great research — to claim some languages are greener than others. That&#39;s an oversimplification.
<ol>
<li>We can always change compilers and runtimes to be more efficient, so it&#39;s hard to attribute energy use to the language alone. OK, that&#39;s me being pedantic.</li>
<li>Is the faster one also the most energy-efficient? Well... Energy = Time × Power. This suggests energy will decrease if execution time decreases, but only if power remains constant. Power can vary between runtimes, compilers, and hardware. The paper highlights C as among the most efficient languages in their tests, but that doesn&#39;t always mean it&#39;s the fastest in every scenario.</li>
<li>Hardware. Results may vary depending on the hardware, OS, middleware, drivers, and so on. It&#39;s tricky to point to a single &quot;greener&quot; language because a language is only one part of the whole system.</li>
</ol>
What would be the environmental impact of rewriting every application in C? It could be huge — and it&#39;s hard to predict.
4. Erlang uses concurrency by design. That language/runtime design made it resilient and practical for telecom applications in the 1980s. Even if both Erlang and C are fully optimized, reimplementing the same resilient applications in C might not yield the same results.
We can use this paper to inform our choices, but we should be careful not to oversimplify the conclusions or reinvent the wheel every time. The study is nuanced and shouldn&#39;t be reduced to &quot;let&#39;s use C because it&#39;s the most efficient.&quot; Drawing that single conclusion would be misleading.
In short: there is no single &quot;greener&quot; programming language. Energy use depends on algorithms, compiler and runtime behavior, hardware, and system design. When energy matters, measure the whole stack, choose the right tool for the job, and prioritize algorithmic efficiency and appropriate hardware.
<hr>
Talk soon,
Victor Fulgêncio

There should be a programming language more suitable to the environment, right?

Is there a greener programming language?

<h2 id="getting-started">Getting Started</h2>
To produce sound waves with elixir - and be able to listen to them - we&#39;re going to use the library <a target="_blank" rel="noopener" href="https://github.com/bitgamma/synthex">synthex</a> alongside with Sound eXchange, or sox. 
First, let&#39;s be sure we have sox installed and it&#39;s configured in your PATH:
For mac, just run the following homebrew command and you&#39;re good to go.
<pre><code class="language-bash">brew install sox
</code></pre>
For Windows, the easiest option is install it using <a target="_blank" rel="noopener" href="https://community.chocolatey.org/packages/sox.portable">chocolatey</a>.
If you&#39;re a Debian/Ubuntu user, you can run:
<pre><code class="language-bash">sudo apt-get install sox libsox-fmt-all
</code></pre>
<blockquote>
For more &#39;sox&#39; references, check out their official <a target="_blank" rel="noopener" href="http://sox.sourceforge.net">page</a>
</blockquote>
<h2 id="elixir">Elixir</h2>
Let&#39;s create a simple module:
<pre><code class="language-bash">mix new noisemaker
</code></pre>
Let&#39;s also add the <code>synthex</code> lib as dependency in <code>mix.exs</code>:
<pre><code class="language-elixir"># file: mix.exs
defp deps do
 [{:synthex, &quot;~&gt; 0.0.1&quot;}]
end
</code></pre>
<blockquote>
Remember to run <code>mix deps.get</code> after adding the library.
</blockquote>
<h3 id="synthex-a-signal-synthesis-library-for-elixir">Synthex: A signal synthesis library for elixir</h3>
This is a very simple library, but can be used to do some great audio synthesis. It also comes with a <a target="_blank" href="https://github.com/bitgamma/synthex/tree/master/examples">few examples</a> that can we can use to validate our environment.
The following script is the simplest example provided: a sine wave with a fixed frequency (A4 in this case: 440 Hz ).
<pre><code class="language-elixir">defmodule Sine do
 alias Synthex.Context
 alias Synthex.Output.SoxPlayer
 alias Synthex.Generator.Oscillator

 @rate 44100

 def run(duration, frequency) do
 {:ok, writer} = SoxPlayer.open(rate: @rate, channels: 2)

 context =
 %Context{output: writer, rate: @rate}
 |&gt; Context.put_element(:main, :osc1, %Oscillator{algorithm: :sine, frequency: frequency})

 Synthex.synthesize(context, duration, fn (ctx) -&gt;
 Context.get_sample(ctx, :main, :osc1)
 end)

 SoxPlayer.close(writer)
 end
end

Sine.run(5, 440)
</code></pre>
You can obviously copy and paste this code inside the file <code>noisemaker/lib/noisemaker.ex</code> and then run <code>mix run</code> to be able to listen the first noise we made with elxir. Remember to lower the volume down.
<h3 id="changing-a-bit">Changing a bit</h3>
Ok. This is the sound of a sinewave of 440 Hz. Let&#39;s try to produce this same note using square waves. To achieve this with <code>synthex</code>, just change the algorithm used by the Oscillator:
<pre><code class="language-elixir">context =
 %Context{output: writer, rate: @rate}
 |&gt; Context.put_element(:main, :osc1, %Oscillator{algorithm: :pulse, frequency: frequency})
</code></pre>
<blockquote>
Before running this, be sure to decrease the volume from your computer.
</blockquote>
The sound produced by a square wave with the frequency of 440 Hz is a bit disturbing, isn&#39;t it? Besides, why does the volume seem to be higher?
Well, square waves have more then the base frequency inside it. Unlike a sinewave, a square wave needs higher frequencies to sharpen the rising and falling edges, besides it&#39;s fundamental frequency (of 440 hz). Theoretically, they have have infinite bandwidth. 
That&#39;s why they sound different, because they really should, as square waves uses more higher harmonics. 
The volume of a square wave is also higher, but we din&#39;t change the amplitude of the signal. Well, a square wave is this library has it&#39;s amplitude fixed in 1, which is the maximum value of a pure sinewave.
<hr>
Cool stuff. Let&#39;s make some sound with <code>Synthex</code> and Elixir then.
Talk soon, 
Victor Fulgêncio.

How to install synthex lib and make some sound using elixir

Making some noise with elixir

Hi there! 
I&#39;m Victor Fulgêncio, a software and telecommunications engineer with some experience working as a backend engineer for the web, but also with a great interest in audio and signal processing.
If you wish to know more about my career, let&#39;s connect on <a target="_blank" rel="noopener" href="https://br.linkedin.com/in/victorandrade4/?locale=en_US">LinkedIn</a>, or check out my projects on <a target="_blank" rel="noopener" href="https://github.com/VictorAndrade4">GitHub</a>.
Hope you find some of my blog posts useful somehow ;)

victorfulgencio

Blog