Write something in python

>write something in python
haha that's so slo-
>compile in cython
HEY NO FAIR YOU DIDN'T WASTE TIME LIKE I DID!!! STOP THAT!!!!!!

Attached: 1522377865903.jpg (960x960, 73K)

Other urls found in this thread:

benchmarksgame-team.pages.debian.net/benchmarksgame/faster/c.html
twitter.com/SFWRedditImages

I know nothing about cython, but the advantage of C performance doesn't come from the fact that "it's C", it comes from the fact that by writing your code in a lower level you can write more efficient code and take shortcuts because you're not using big abstracted blocks.
High level languages are never going to be more efficient than low level languages, but that's not the purpose of them.

He's right, you know

>write something in python
haha that's so slow
>compile it in cytho-
Doesn't compile, have to modify the code.
>compile it in cython
Its faster but still not fast because of all the python data types overhead.
>whatever I just run it in pytho-
Code doesn't work in python anymore.

Except C++ which is C with tons of syntactic sugar macros.

t h i s
still cython's existence is overall a positive

>compile in cython
It's still slow, unless you basically use it to write semantic C++ but with less support. At that point C, C++ and other low level languages are the less painful option.
See With PyPy it's similar. Current Python semantics don't allow fast execution.

>C
>low level language

saying syntactic sugar is syntactic sugar

There's a couple of levels below C and about a billion above, C is low level.

Can cython use the new type hinting from python 3?

Just checkout the previous version from your git repo.

>There's a couple of levels below C and about a billion above, C is low level.
There aren't a "couple" of layers between C and the hardware. There isn't a couple of layers between Assembly and the Hardware. There isn't even a couple layers between microcode and the hardware. C is a high level language. The leap between C and Python is a thousand times smaller than the leap from C to raw machine code. C has no direct relationship to a modern x86 processor.

>With PyPy it's similar.
But doesn't PyPy accept native CPython 3.5 code? I don't think you would need to rewrite your code for it to run on PyPy.

What? It comes from being a compiled language. Christ, when did Jow Forums become this dumb. Ever noticed how every compiled language is faster than every interpreted language? The conversion to machine code is done before runtime.

C++ is most definitely not just sugar for C. Unless you're being pedantic about the definition, in which case literally all languages are syntactic sugar for assembly. The compiler makes all the difference user.

Are you retarded?

Being close to hardware doesn't make a language fast. Having no modern features doesn't make a language fast either. Have a good day.

This is true but you're still retarded. A large part of it literally is the fact it's C, the compiler itself. Code written in C will always out perform code that does the same thing in any other language bar assembly.

>what is git

>Not using a mutt language like Julia
>First run is slow like Python
>Second run is faster than C
Eat shit purists, mutts 4 life.

compiled Haskell code is faster than C anyways
referencial transparency and strong type system allows a compiler to get away with a lot of things.

C++ however is faster and offers higher level abstractions. How come?

>couple of levels
I know this is bait but I'll bite:

People who think this shit in real life are insufferable faggots who have 0 concept of how much abstraction there already is between them programming in "real" languages bare metal. The amount of abstraction that's achieved by going from logic gates to C is fucking astronomical, and you could probably never achieve writing a C compiler from bare metal in your entire life if it weren't for the work of hundreds of years of mathematicians working all this shit out for you. Comparatively, the jump from C to Python is minuscule in the grand scheme of things. Sure it might abstract away a few data structures and make things nicer to use, but it's nothing compared to carefully organizing bits of sand together in such a way that they perform actual computation.

Computer science and abstraction are tied together at the hip. Losers who can't understand that the continuous abstraction of mathematics is the very essence of computing are the most obnoxious fucking faggots in the world. The losers who can't understand that it's actually harder to think abstractly are the funniest of them all. Sure you can do the equivalent of hand-holding a modern abacus. You're not accomplishing anything by reinventing the wheel for the thousandth time, you're just doing it because someone needs some retarded shit to be fast, but you're not furthering the field of computer-science. You're not developing new fucking algorithms in C, you're implementing something that someone (far smarter than you) has already thought of in a slightly different flavor just so you can get a paycheck.

Wow, great response. Did your fantasy world where C is a low level language just crumble?

Wew

>when did Jow Forums become this dumb
>become

*overflows your buffers*

>Change part of the program
>Get a runtime error because lol no types

I think you’re mistaking a lot of recursion and substitution for being “lower level.” With enough macros, assembly can basically look like C.
You can more or less do renamed opcode things in C as well.
I’d say there’s a difference of kind in both directions, not just between C and bare metal.

I love the fact that ignorant people such as this tard exist, not only do I love it, I encourage it, less competition for desirable positions.

>I was in FIRST robotics club in high school: the post

this
Why are you comparing it with assembly? When was your last time you wrote your own language from hdl up ?

The higher you go on the abstraction level the more you achieve with each abstraction, so there will always be more abstractions on the lower spectrum, it's a snowball effect.

Attached: index.jpg (225x225, 5K)

uh oh

Attached: Capture.png (701x857, 53K)

nice cherrypicking, you mongoloid

they're often too close to call, and in the rare event where there is a meaningful difference, C is usually faster.
benchmarksgame-team.pages.debian.net/benchmarksgame/faster/c.html

It does, but for improving performance it really wants you to use it in an incompatible way. See FFI and stuff.
>It comes from being a static language.
ftfy
>And it's still reported for being slower than necessary and of course with LLVM the compiler is slow.
Imagine what they could have gained if they had created a proper static high level language instead.

>uses never/always
>gets proven otherwise
>complains about cherry picking
Are you perhaps retarded ? If you don't know what words mean, don't use them.

Suppose you had a computer with four processors.
And a language that could automatically parallelize even simple tasks such as splitting strings or adding numbers together.
So in your language you had a statement such as
int result = var1 + var2 + var3 + var 4 + var5 + var6+ var 7

What your low level C would do is perform every addition sequentally, each addition performed on the value of the pevious one.

Now, a more elegant way of doing this would be a reduction. Your code could make a call like
result = reduce(+(), var1, var2, var3, var4, var5, var6, var7)

Where +() is a function taking two arguments and returning their sum and reduce calls its first argument on the result of the first call and the first remaining argument.
Now, if your compiler knows that +(A, B) is always equal to +(B, A), it knows that the order of the arguments to the above call to reduce aren't important, and that multiple of these calls can be made in parallel without affecting the outcome.
So a parallerizing optimizining compiler would produce code that spawns three working threads. They get the first three pairs of the arguments and perform an addition with them, and the first that finishes adds the last argument to its intermediate value. The rest go add intermediate values together until the whole thing is reduced to just one value.
This sort of thinking is not viable for a low level language where you need to be in control of things, but it would improve performance in a lot of things that software is now doing linearly. C will never reap the benefits of mathematical compiler optimizations and as soon as the world is ready it will no longer be the 'performance' language.

>t. knows nothing about computer architecture

Imagine being this stupid

Would you say this is something that's a pain to implement in C over something like Go (I hear multithreading is like this) or is it something that has to be built into the compiler itself? Because in the former case it's just a matter of effort vs reward in using C, but with that theoretical effort you get the theoretically fastest speeds

>durr what's a .pyc

Not an argument