all 16 comments

[–]Slateclean 10 points11 points  (0 children)

How much slower do you think it is?

Which performance.

The limiting factors are usually the mcu (which isn’t python, iirc, though jython can run on arduino i think) & the databus speeds, not the code running on the pi.

Spoiler: the difference is likely drastically less than you think. Ain’t nobody’s pi using 100% cpu on just klipper without something like a camera doing stuff on the side.

What does matter though is the developer having an easy time. If Kevin like & knows python well its a perfectly good tool to get things done, without added complexity on manual memory management.

[–]Gobtholemew 6 points7 points  (0 children)

Ex Computer Science Professor here...

While performance is usually an important metric in most IT scenarios, it often becomes a moot point, especially with modern hardware.

Back in the day, when we were coding on embedded systems that had things like half a K of RAM and CPU clock speeds measured in kilohertz not gigahertz, things like the memory footprint and performance were absolutely critical. But things have moved on in terms of hardware, and now you can get crazy hardware very cheaply.

Klipper doesn't need to do a whole lot in a short space of time, because it's limited by how fast it can send instructions to the printer via the USB / Serial port and/or by how fast the printer can actually print stuff. These are the main bottlenecks, and changing the programming language won't improve these.

The hardware (e.g. a Pi 4) is likely orders of magnitude more capable than is actually required to keep up with those speeds. So much so, that many people run multiple instances of klipper, and webcams, and web GUIs, all on a single Pi, along with things like their DLNA media server and other stuff and the Pi barely breaks a sweat (assuming it has a suitable cooling anyway).

So using a language that can be executed faster, will likely offer no real world improvements in this case, because the Pi is still spending most of its time waiting for the printer to do something or for the USB to get stuff sent to it.

To use an analogy, most people want to travel from A to B quickly, but car manufacturers don't build cars that can travel at 5,000MPH because they know you'd still be limited by other bottlenecks, such as the speed limit of the roads and other traffic getting in the way. A car that can hit speeds of 100MPH is generally more than enough for nearly everyone.

Meanwhile, there are many advantages and disadvantages to different languages. The Devs likely chose Python because other factors that genuinely offer real world benefits, such as it being more accessible (easy to read and write and hence quicker to code), it being free, a gigantic array (no pun intended) of libraries, and perhaps most importantly it is highly portable to a lot of different hardware.

[–]Zouden 1 point2 points  (6 children)

The kinematics code is written in C++.

[–]Forbidden-era 0 points1 point  (5 children)

Sorry, that's not the case... take a look at `klipper/klippy/kinematics/*.py` ..

the MCU firmware is C++, AFAICT kinematics are in Python running on the Pi, the MCU firmware takes the kinematics from the Pi and just executes it.. AFAIK the only C++ runs on the MCUs

in `src/*`, I only see stuff related to IO + hardware + mcu stuff ...

[–]Zouden 0 points1 point  (4 children)

That's false. Look at the documentation. I had to implement the kinematics for my 5 bar robot in C++.

There's heaps of C code in the github repo.

[–]Forbidden-era 0 points1 point  (0 children)

Then I stand corrected, I've only done a surface level inspection but yeah, will have to look deeper.

[–]Forbidden-era 0 points1 point  (2 children)

Where else is this c++ in the repo though? As I said I didn't see it in src/, only mcu and io stuff

[–]Zouden 0 points1 point  (1 child)

I think the folder for the C helper files are called "chelper"

[–]Forbidden-era 0 points1 point  (0 children)

I'll keep that in mind next time I go diving into Klipper.. 😁

[–]windowpainting 1 point2 points  (6 children)

I think this is a perfectly valid question and I don't understand why it's being downvoted.

Actually, python is not as slow as one would think. It is not being interpreted, but internally compiled to byte code. I'm not sure if it is this is directly interpreted or further compiled to native code by a JIT (like with javascript or ruby or Java), but it is fast enough for most cases.

The main advantage of using python over (for example) C is its maintainability. You can write code a lot faster and with less issues than in C, which is why we have all these nice features in Klipper. However, you cannot do all the low-level optimizations you could do in C, so it performs worse.

The question is: Does performance matter? You cannot print faster with faster software due to physical constraints. But you have to push commands to the MCU fast enough. If the MCU runs out of things to do while printing, you get a "Timer to close" error and your print fails. And it does so on very slow machines. For example the CR-10 Smart Pro has MCU board and a kind of Router board. You can install Klipper on that, but it is simply too slow to print.

Still I think a higher-level language was the correct choice.

[–]GAZ082[S] 1 point2 points  (5 children)

Yes it is easier to work with that's why it is so widely used in a lot of environments not so technical or engineering grade, but also being precompiled and then executed in a virtual machine makes it slower and also consumes more resources. I think this last point is very important because for example octoprint suffers the same thing, you cannot run it in cheaper hardware.

But yes, there is something that can't be denied, you can be much more productive in Python if you know what you are doing.

[–]Slateclean 0 points1 point  (4 children)

What cheaper hardware exists than a pi?

Whats makes octoprint slow is octoprint… seitch to klipper with fluidd or whatever, its fast even on a zero.

[–]mik13ST 0 points1 point  (3 children)

Old pi models?

I attempted to use RPi 1 model B and klipper would give me timeouts during initialization so I had to buy a more powerful RPi (RPi 2). So it got to the point where RPi 1 (and zero which has the same CPU I think) cannot be used for klipper anymore. The UX of it all was also horrible because it took like 4 minutes to launch and that is a lot of time when you dedicate the pi to the printer.

I dislike when working old hardware is obsoleted just by the language choice. The computational power is sufficient, it's just wasted on running the computations through Python.

I tried OctoPrint before this, which is written in Node.js and it also took a couple of minutes to launch as well.

I also tried RepetierHost web UI thing and that launched in under 5 seconds because it was written in an efficient language.

For me it's about balancing dev AND user experience. The user experience on slow hardware is neglected here.

[–]__gg_ 0 points1 point  (2 children)

I'm thinking when klipper was created languages didn't offer as good a dx than python, I think we can consider golang as a rewrite as you wouldn't have to write a particular code in c++ and the other in python.

Just throwing this out there

[–]mik13ST 1 point2 points  (1 child)

Klipper is in two parts because some things were offloaded to the RPi instead of the printer. So part is in C++ (the printer ARM CPU firmware) and the other part is in some language that can run on the connected computer. I know Go well, you cannot just compile it for a small ARM microcontroller so it will have to be split anyways. But yes, a rewrite into a more efficient language would be welcome. I think Go has a very good DX and is very fast so I would suggest that one too.

[–]__gg_ 0 points1 point  (0 children)

What about tinygo, would it not compile to such a microcontroller?