# Releasing Etaler - A very fast and flexable HTM framework with full GPU support

**URL:** <https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077>\
**Category:** Implementations\
**Tags:** htm-implementations\
**Created:** [May 27, 2019, 1:09pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077 "2019-05-27T13:09:34Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [May 27, 2019, 1:09pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/1 "2019-05-27T13:09:34Z")

</div>

Hello all.  
I’m very excited to finally release a part of my graduation project - Etaler, a very flexible high-performance HTM framework.

* * *

## Why build Etaler

NuPIC is research orientated, and thus it is not that fast. I think that’s one of the reason why we are still stuck at small scale experiments. Inference and learning on NuPIC of a 8192x16 TM can take up to 3 seconds per time step. That’s a big problem for me working on realtime SMI (Sensor motor inference)/RL(Reinforcement Learning). Therefor I set out to make my own framework. And make sure it is fast.

## Features

Etaler is designed around these concepts.

1. Integrated Tensors
2. Separate fronted/API and backend
3. Data Orientated Design as first class citizen
4. Attempts to support research

### Tightly Integrated Tensors

Instead of relying on libraries like `numpy` or `xtensor` to handle multi-dimensional arrays (Both of them don’t support GPU). Etaler implements it’s own Tensors. Which are tightly integrated into the core framework. And can be easily extended. Allowing easy future development.

And… These Tensors support broadcasting, GPU acceleration and basic indexing. 😃

### Separate fronted/API and backend

Etaler provides different backends to run on different devices. While all the backends are connected to the same frontend API. Enabling simple optimization strategies and the ability to run on the GPU with on line of code change. Like how most DL framework works.

### Data Orientated Design

Like most modern Deep Learning frameworks, Etaler uses a DOD approach to it’s design, for example, instead of having a class called `Synapse` which stores a connection target and a permanence. Synapses are described as two Tensors, one storing the connections to other neurons and one storing permanences. Reducing the amount of memory access and increasing efficiency.

A data orientated approach also results in highly reusable API. Now writing new layers is like writing tensor operators in DL frameworks - just write some code that chains the operations together. No more inheritance hell when developing new layers!

### Supporting research and innovation

Being an very ambitious goal. I designed Etaler to support future research and communication between researchers and developers/hobbyists. By supplying a clean and high-performance interface, researchers need not to invent their hacks to have the system running at speed while devs/hobbyists shares their ideas with clear, expressive code. Less loop, less conditions, just function calls.

To support the previous two clams, TemporalMemory with apical synapses can be implemented in just a few lines.

```auto
auto compute(const Tensor& x, const Tensor& apical, const Tensor& last_state)
{
	et_assert(x.dimentions() == 1);//This is a 1D implementation

	//Feed forward TM predictions
	auto [pred, active] = TemporalMemory::compute(x, last_state);

	//Apical feedback
	Tensor feedbacks = cellActivity(apical, apical_connections, apical_permance, 0.21, 3);

	//Cells only predict if it feedback is active when there is more than 1 cells active in a column
	auto s = pred.sum(1);
	pred = pred&&(s>1 && feedbacks) || (s==1 && pred);
	return {pred, active};
}

void learn(const Tensor& active_cells, const Tensor& apical, const Tensor& last_active)
{
	//Let the distal synapses grow and learn
	TemporalMemory::learn(active_cells, last_active);

	//Let the apical synapses learn
	learnCorrilation(apical, last_active, apical_connections, apical_permance, 0.1, 0.1);
	growSynapses(apical, last_active, apical_connections, apical_permance, 0.21);
}

```

## Performance

On CPU, Etaler is as fast as if not slightly faster my previous framework, tiny-htm. On an adequate GPU, Etaler outperforms any other framework by a huge margin.

Performance of SpatialPooler:  
(9000 input bits, 9000 output bits, 10% target density, no boosting, no topology, 75% potential pool, potential radius = 4500, leaning enabled, random scalar encoded input)

| | NuPIC.core | tiny-htm | Etaler |
| --- | --- | --- | --- |
| Processor | R7 1700X - 1 core | R7 1700X - 16 cores | RTX 2080Ti |
| Time | 181ms | 25ms | 6.9ms |

![image](https://canada1.discourse-cdn.com/flex030/uploads/numenta/original/2X/6/6505ad206f637572a749ab2d11703e383a9b9f74.png)

Performance of Temporal Memory:  
(8192 columns, 16 cells per column, max 1024 synapses per column. [tiny-htm](https://discourse.numenta.org/t/a-flexable-framework-for-htm-algorithms-and-another-htm-implementation-no-one-asked-for/5398) and Etaler using the connect-to-all method described [here](https://discourse.numenta.org/t/exploring-the-repeating-inputs-problem/5498/5))

| | NuPIC.core | tiny-htm | Etaler |
| --- | --- | --- | --- |
| Processor | R7 1700X - 1 core | R7 1700X - 16 cores | RTX 2080Ti |
| Time | 3074ms | 36.8ms | 4.91ms |

![image](https://canada1.discourse-cdn.com/flex030/uploads/numenta/original/2X/3/33c5cc8b8976dfac3655a48b2daf428c1ebbb761.png)

- NuPIC.core compiled with clang 8.0.0 (running into linking issues with GCC)
- tiny-htm compiled with GCC 8.3.0
- Etaler compiled with GCC 8.3.0
  - RTX 2080Ti benchmarked using Nvidia’s official OpenCL SDK.

## OS/Device support

Etaler has only been tested and proven to work on the following systems. According to the results, there is no reason to not work on others systems.

| | system1 | system2 | system3 | system4 | MacBook Air |
| --- | --- | --- | --- | --- | --- |
| OS | Arch Linux | Arch Linux | Arch Linux | Manjaro Linux | OS X |
| CPU | R7 1700X | I7 8700 | I5 8250U | I7 6700 | I5 5250U |
| GPU | GTX 780Ti | RTX 2080Ti | HD 520 | GTX 970 | HD 6100 |

- For Intel iGPUs, tesed on the new [Neo OpenCL SDK](https://github.com/intel/compute-runtime)
  - Using the [built-in OpenCL SDK](https://developer.apple.com/opencl/) on OS X

- For NVIDIA GPUs, tested on both [official OpenCL SDK](https://developer.nvidia.com/opencl)
  - GTX 780TI is also tested with [POCL w/ CUDA backend](http://portablecl.org/)

- OpenCL on CPU is not tested.
- I want to test Etaler on an AMD card, but not having the budget to get one. ☹
  - Radeon VII (7nm Vega + HBM) theoretically should be faster than a RTX 2080 since the main limitation is the memory bandwidth.

- Etaler is build-able under Windows using MSYS2. But crashes immediately due to a MSYS2 specific compiler bug (the resulting DLL is not loadable). Other build environments are not tested.
- I see no reason not working on ARM.
- Built with GCC and stdc++ on OS X.

## Future plans

I’m planing on long term supporting/developing Etaler after my graduation project if there is enough interest. There are some features I want to add to Etaler but don’t have the time to do so yet.

- port htmresearch layers
- More optimization (2x performance on GPU is may be feasible)
- Python wrapper
- More numpy-style array operators
- Graph more/lazy evaluation
- Better documents
- Support ongoing research
- Batch execution (optimization for Thousand Brains Theory)
- Windows support
- etc…

I believe Etaler can be a great tool pushing HTM theory forward, accelerating experiments and promoted innovation. But it is in it’s early stages and I’m not going to make it just by myself. If you think Etaler is a project you are interested in, by all means.

The easiest way to help is by using the library. If you find a bug or a missing feature, please open an issue and let us know how we can improve. If you want to develop the library it self, you are very welcomed! We are excited to see a new PR pop up.

## Contribution

HTM Theory is in it’s young age and as we are growing. We’d like to get contributions from you to accelerate the development of Etaler! Just fork, make changes and launch a PR!

## Special Thanks

A very huge thanks to @LiorA testing the framework, making a Dockerfile and now working on Layer visualizations. Thank you! Your work is amazing.

Also, thank you to all forum/Discord members. I won’t be able to go so far without you. I have learned a lot from the community and I love you awesome geeks!

# Where is the source!

(I’m still working on the logo for the projerct. Hang on!)

> **[etaler/Etaler](https://github.com/etaler/Etaler)**
>
> A flexable HTM (Hierarchical Temporal Memory) framework with full GPU support. - etaler/Etaler

And extra examples.

> **[etaler/etaler-examples](https://github.com/etaler/etaler-examples/)**
>
> Contribute to etaler/etaler-examples development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![abhishek](https://avatars.discourse-cdn.com/v4/letter/a/7ba0ec/32.png) [@abhishek](https://discourse.numenta.org/u/abhishek)\
**Post date:** [May 27, 2019, 2:10pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/2 "2019-05-27T14:10:02Z")

</div>

Looks promising. Does it also have opf with anomaly detection or is the plan to just the port of nupic.core ?

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [May 27, 2019, 3:03pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/3 "2019-05-27T15:03:58Z")

</div>

It is a entire new framework. Having nothing to do with NuPIC.core. But it is designed in a way that is very close to how a ordinary DL frameworks. So when we eventually have Python wrapper working, you can slap any data streaming framework for DL and it should work.

---

<div class="post-metadata">

**Author:** ![abhishek](https://avatars.discourse-cdn.com/v4/letter/a/7ba0ec/32.png) [@abhishek](https://discourse.numenta.org/u/abhishek)\
**Post date:** [May 27, 2019, 3:42pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/4 "2019-05-27T15:42:15Z")

</div>

Got it. Thanks 🙂

---

<div class="post-metadata">

**Author:** ![Paul\_Lamb](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/paul_lamb/32/2725_2.png) [@Paul\_Lamb](https://discourse.numenta.org/u/Paul_Lamb)\
**Post date:** [May 28, 2019, 1:58pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/5 "2019-05-28T13:58:29Z")

</div>

Nice work, @marty1885 – thanks for sharing!

I thought I would mention a few observations on differences between Etaler and the official TM algorithm. I am not claiming any of this to be wrong – just some points worth noting. I am not very familiar with the specific .cl file syntax, so please correct me if I have misrepresented anything.

1. The TM algorithm appears to only be growing one segment per cell. This is also implied by some of the variable names (such as MAX\_SYNAPSE\_PER\_CELL). @scott commented on this optimization idea on [another unrelated thread](https://discourse.numenta.org/t/htm-process-optimizations/2708/8). He mentioned that this is a reasonable optimization and that the algorithm would still work. The cost would be increased likelihood of false positives once you get up to around 10-15 predicted patterns, and he mentioned that this could be mitigated with the right learning rates.

2. The cells chosen for learning in the current timestep will grow synapses with any cells that were active in the previous timestep (see [here](https://github.com/etaler/Etaler/blob/master/Etaler/Algorithms/TemporalMemory.cpp#L34) for example). This differs slightly from the official algorithm, where they will grow synapses only with winner cells that were active in the previous timestep (see [here](https://github.com/numenta/nupic/blob/master/src/nupic/algorithms/temporal_memory.py#L631) for example).

3. It appears that every learning cell will connect with every previous active cell, up to MAX\_SYNAPSE\_PER\_CELL. This differs from the official algorithm, where the number of new synapses grown in a single timestep can be throttled with [maxNewSynapseCount](https://github.com/numenta/nupic/blob/master/src/nupic/algorithms/temporal_memory.py#L79). While I haven’t tested this, I would expect that not having maxNewSynapseCount might lead to behavior similar to what is described in [this thread](https://discourse.numenta.org/t/suggest-change-to-sequence-memory-algorithm/6011). If so, this could probably be mitigated by keeping MAX\_SYNAPSE\_PER\_CELL sufficiently low.

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [June 2, 2019, 2:19pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/6 "2019-06-02T14:19:52Z")

</div>

Sorry for the late reply. I was too busy lately.

1. Yes, I think that is due to the fact that I follow the pesudo code from from the original HTM Whitepaper.

2. Yes, I use a modified version of the learning algorithm to avoid the repeated input problem that is plaguing TM. Thus it is advised to decay unused synapses every while to clean space out for new ones.

3. Hmm… Good point that I didn’t catch. I’ll think about it.

---

<div class="post-metadata">

**Author:** ![michaelklachko](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/michaelklachko/32/14_2.png) [@michaelklachko](https://discourse.numenta.org/u/michaelklachko)\
**Post date:** [June 4, 2019, 11:13pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/7 "2019-06-04T23:13:34Z")

</div>

Congrats on your graduation! I’m a bit confused though, why didn’t you use an existing tensor library?

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [June 5, 2019, 2:17am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/8 "2019-06-05T02:17:24Z")

</div>

A few reasons. First, most of them run on CUDA with no OpenCL support. But with OpenCL I can run on any GPU and even FPGA. Secondly, I can’t find a tensor library that both a) supports multiple GPU and b) allow easy extension (so I can add HTM algorithms to the tensor operators).

* * *

**Edit** : I’m still a while from graduation. It’s a must-do project, but I’m still at least a year from graduation.

---

<div class="post-metadata">

**Author:** ![breznak](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/breznak/32/1935_2.png) [@breznak](https://discourse.numenta.org/u/breznak)\
**Post date:** [July 11, 2019, 10:50am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/9 "2019-07-11T10:50:28Z")

</div>

Impressive work, @marty1885 ! 👏

The API seems really nice to use and I applaud to the HW-agnostic design.

Could you give some short comparison to HTM whitepaper, or nupic, nupic.core? In terms of feature parity, custom-design decisions (like that in TM), API compatibility.

> [@marty1885](#):
>
> ## Future plans
> 
> I’m planing on long term supporting/developing Etaler after my graduation project if there is enough interest. There are some features I want to add to Etaler but don’t have the time to do so yet.
> 
> - Python wrapper
> - Windows support

Would it be possible to integrate your work as a GPU backend to htm.core (community of nupic.core)?  
We have multiplatform c++, and python wrappers. So if we can relatively easily write c++ wrapper for SP, TM then your work should nicely integrate there.

> [@marty1885](#):
>
> ## Performance
> 
> On CPU, Etaler is as fast as if not slightly faster my previous framework, tiny-htm. On an adequate GPU, Etaler outperforms any other framework by a huge margin.
> 
> Performance of SpatialPooler:  
> (9000 input bits, 9000 output bits, 10% target density, no boosting, no topology, 75% potential pool, potential radius = 4500, leaning enabled, random scalar encoded input)
> 
> | | NuPIC.core | tiny-htm | Etaler |
> | --- | --- | --- | --- |
> | Processor | R7 1700X - 1 core | R7 1700X - 16 cores | RTX 2080Ti |
> | Time | 181ms | 25ms | 6.9ms |
> 
> ![image](https://canada1.discourse-cdn.com/flex030/uploads/numenta/original/2X/6/6505ad206f637572a749ab2d11703e383a9b9f74.png)

Are you using local inhibition in the SP?  
Because if not, I have competitive results. Please see if I’ve replicated your benchmark correctly,

> **[GitHub - htm-community/htm.core at speed\_comparison](https://github.com/htm-community/htm.core/tree/speed_comparison)**
>
> speed\_comparison

I use: 9000 inputs, 9000 outputs, SP global inh, 10% sparsity, 75% potential pool, 4500 pot radius.  
TM 9000 cols (yours 8128), 16 cells/col,

If you run the benchmark:  
`nupic.cpp/build/scripts$ cmake ../.. && make -j8 mnist_sp benchmark_hotgym && ./src/benchmark_hotgym 1000`

It prints time in secs for 1000 runs, so exactly your `ms/iteration`:

> ==============TIMERS============  
> Init: 0.273688  
> Random: 0.262973  
> Encode: 0.0273115  
> SP (g): 1.69396  
> TM: 19.2002  
> AN: 0.00640459  
> Total elapsed time = 21 seconds

So we get `SP 1.7ms/iter` and `TM 19ms/iter`. Would you include htm.core to your comparison?

PS: I wonder what the runtimes are on FPGAs? Do you have some results?

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [July 11, 2019, 12:53pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/10 "2019-07-11T12:53:54Z")

</div>

@breznak Thanks you! I have been closely following HTM.core’s progress. Great job on refactoring and optimizing NuPIC.core!

> [@breznak](#):
>
> Could you give some short comparison to HTM whitepaper, or nupic, nupic.core? In terms of feature parity, custom-design decisions (like that in TM), API compatibility.

Sure! I’ll make some comparisons to the whitepaper and post it later on.

Well… I believe API compatibility basically doesn’t exist. NuPIC uses numpy arrays, NuPIC.core use raw pointers, HTM.core uses the SDR class and Etaler uses it’s own Tensors. Besides that, though Etaler’s API is based on NuPIC.core’s. I have made a lot of changes. Mainly

1. Encoder/Decoders are now plain function calls. Not objects
2. The `compute()` function of SP/TM is const. Learning is done by the `learn()` function
3. Non-intrusive serialization instead of intrusive.
4. Using Tensors instead of separate SDR/vector of something
5. etc…

> [@breznak](#):
>
> Would it be possible to integrate your work as a GPU backend to htm.core (community of nupic.core)?  
> We have multiplatform c++, and python wrappers. So if we can relatively easily write c++ wrapper for SP, TM then your work should nicely integrate there.

As much as I would like to say it is possible. I think it is mostly no, Etaler (including it’s GPU backend) have a very different way regarding how data is handled. To be specific, Etaler represents SDRs as a binary tensor, but NuPIC represents SDR as both a binary array and a sparse array. And Etaler represents synapses as two N-dimensional tensor (one for permanence and one for connection target), yet NuPIC as far as I know stores synapses in an array-of-objects.

> [@breznak](#):
>
> Are you using local inhibition in the SP?  
> Because if not, I have competitive results. Please see if I’ve replicated your benchmark correctly,

No, I’m only doing global inhibition. Wow, your speeds are amazing! I’ll check it out in the weekends.

> [@breznak](#):
>
> PS: I wonder what the runtimes are on FPGAs? Do you have some results?

I haven’t get around to port my OpenCL kernels to a FPGA yet. ☹ It is going to be very time-consuming and it’s not high on my list of priorities. I’ll get to it eventually. (And I have someone working on a low-power Verilog core for embedded systems. But that’s in a very early stage)

---

<div class="post-metadata">

**Author:** ![Jose\_Cueto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/jose_cueto/32/4052_2.png) [@Jose\_Cueto](https://discourse.numenta.org/u/Jose_Cueto)\
**Post date:** [July 28, 2019, 11:48pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/11 "2019-07-28T23:48:46Z")

</div>

Hey @marty1885, I’m getting the following error while building in my mac. I’ve just followed the instructions in the readme. I’ve already installed TBB, how is this resolving the header files?

```auto
[10%] Building CXX object Etaler/CMakeFiles/Etaler.dir/Algorithms/SpatialPooler.cpp.o
[10%] Building CXX object Etaler/CMakeFiles/Etaler.dir/Backends/CPUBackend.cpp.o
/Users/admin/mlearn/Etaler/Etaler/Backends/CPUBackend.cpp:8:10: fatal error: 'tbb/tbb.h' file not found
#include <tbb/tbb.h>
         ^ ~~~~~~~~~~
1 error generated.
make[2]: *** [Etaler/CMakeFiles/Etaler.dir/Backends/CPUBackend.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Etaler/CMakeFiles/Etaler.dir/all] Error 2
make: *** [all] Error 2

```

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [July 29, 2019, 3:48pm UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/12 "2019-07-29T15:48:53Z")

</div>

Sorry for the delayed reply. I’m on a trip to another Univ to collaborate with other projects.

Hmm… how did you installed TBB? I installed it from homebrew.

---

<div class="post-metadata">

**Author:** ![Jose\_Cueto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/jose_cueto/32/4052_2.png) [@Jose\_Cueto](https://discourse.numenta.org/u/Jose_Cueto)\
**Post date:** [July 30, 2019, 12:21am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/13 "2019-07-30T00:21:02Z")

</div>

I used homebrew to install it.

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [July 30, 2019, 3:33am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/14 "2019-07-30T03:33:11Z")

</div>

Hmm… I have no idea now. May you open an issue so we could keep track of the problem? And I’m on a visit so I don’t have access to a Mac now. I’ll have to solve it next week.

---

<div class="post-metadata">

**Author:** ![Jose\_Cueto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/jose_cueto/32/4052_2.png) [@Jose\_Cueto](https://discourse.numenta.org/u/Jose_Cueto)\
**Post date:** [July 30, 2019, 3:43am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/15 "2019-07-30T03:43:48Z")

</div>

No need to solve it right now, I’ll have another look this weekend and create an issue when necessary.

Thanks

---

<div class="post-metadata">

**Author:** ![LiorA](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/liora/32/1671_2.png) [@LiorA](https://discourse.numenta.org/u/LiorA)\
**Post date:** [August 1, 2019, 7:21am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/18 "2019-08-01T07:21:37Z")

</div>

Hi Jose,  
You can also use a docker environment. Plz see it in [https://github.com/alior101/Etaler](https://github.com/alior101/Etaler) (It’s a fork I’m using for my own tinkering) I will be merged into Martin repo soon but in the meantime you can look at the Dockerfile .

Lior

---

<div class="post-metadata">

**Author:** ![Jose\_Cueto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/jose_cueto/32/4052_2.png) [@Jose\_Cueto](https://discourse.numenta.org/u/Jose_Cueto)\
**Post date:** [August 1, 2019, 9:35am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/19 "2019-08-01T09:35:20Z")

</div>

Hey @LiorA thanks a lot.

---

<div class="post-metadata">

**Author:** ![Jose\_Cueto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/jose_cueto/32/4052_2.png) [@Jose\_Cueto](https://discourse.numenta.org/u/Jose_Cueto)\
**Post date:** [August 7, 2019, 2:30am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/20 "2019-08-07T02:30:52Z")

</div>

Hi @marty1885

I know you’re busy, same here, but I’ve created some issues in etaler repo. When you have a chance please advise, or provide a fix whenever necessary.

Nice to have:

1. 1-step install script per OS
2. Standard docker build (e.g. Dockerfile in root dir)
3. Docker compose file for ease of integrating other apps/systems later on

Comments:  
I’m happy to contribute when I’m able to consistently build this. Also, I would not focus more on the VSC setup as it is very specific and it might not work properly in other local setups. Just my 2 cents.

Thanks

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [August 7, 2019, 8:04am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/21 "2019-08-07T08:04:52Z")

</div>

@Jose_Cueto Thanks!

I think it’s time for me to consider making a stable building environment and maybe have a CI to check stuff. Though having no experience about CIs, it might take a while to have that set up.

I’ll try to get OS X building working again soon.

---

<div class="post-metadata">

**Author:** ![Jose\_Cueto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/jose_cueto/32/4052_2.png) [@Jose\_Cueto](https://discourse.numenta.org/u/Jose_Cueto)\
**Post date:** [August 7, 2019, 8:11am UTC](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077/22 "2019-08-07T08:11:49Z")

</div>

@marty1885 No worries im happy to setup a ci for this as soon as we get a stable build.

[Next page](https://discourse.numenta.org/t/releasing-etaler-a-very-fast-and-flexable-htm-framework-with-full-gpu-support/6077.md?page=2)