but being faster than c is actually trivial and obvious even in the general case... here is something i crapped out 6 years ago to prove the point: https://github.com/semiessessi/CP1
Beating C with Dyalog APL
11–20 of 57 posts
Re: Beating C with Dyalog APL
#12Re: Beating C with Dyalog APL
#13Re: Beating C with Dyalog APL
#14C is a low bar. It has always been slower than Fortran. It has been slower than C++ ever since reasonable optimization was implemented. Anything not faster than C, today, is a slow language, practically by definition.
Re: Beating C with Dyalog APL
#15Re: Beating C with Dyalog APL
#16C is a low bar. It has always been slower than Fortran. It has been slower than C++ ever since reasonable optimization was implemented. Anything not faster than C, today, is a slow language, practically by definition.
Which compilers? Which platforms? Optimized for speed or space (because "faster" is only one dimension of optimization)?
Many C / C++ compiler implementations share the same front ends, back ends and runtime libraries, so it's hard to see how the code generation for C would be much different than that of C++. (In fact, C++ will be harder to optimize if features like exceptions and RTTI are used).
Given the many different commercially and freely available toolchains, this statement is difficult to back up.
Re: Beating C with Dyalog APL
#17Re: Beating C with Dyalog APL
#18Pretty sure the words function can be simplified to {⍴(~⍵∊⍺)⊆⍵} (and it also handles empty strings).
Re: Beating C with Dyalog APL
#19C is a low bar. It has always been slower than Fortran. It has been slower than C++ ever since reasonable optimization was implemented. Anything not faster than C, today, is a slow language, practically by definition.
> It has been slower than C++ ever since reasonable optimization was implemented. Which compilers? Which platforms? Optimized for speed or space (because "faster" is only one dimension of optimization)? Many C / C++ compiler implementations share the same front ends, back ends and runtime libraries, so it's hard to see how the code generation for C would be much different than that of C++. (In fact, C++ will be harde…
For example, in Python you can talk about the GIL and pointer chasing. But you can also talk about Cython. It turns out that, for me, Python's FFI is a really important factor, and a big reason why it's much easier for me to get good performance in Python than it is in Java: It makes it easy to interact with C libraries without taking a big hit on marshaling data in and out of Java's managed heap. (This is, incidentally, a major factor in Python having so thoroughly supplanted Java in the ML/BI/DS/analytics space.) But there are other situations where Java would be the clear winner.
My favorite performance comparison between languages ever was the one that Raymond Chen and Rico Mariani did on implementing a practical program in C# and C++. [1] As it turns out that, at least as of 14 years ago, C++ is faster than C#, and C# is faster than C++, under different circumstances. You've really got to pay attention to which ones matter most to you before deciding where to place your bets, and just paying attention to rankings on The Computer Language Benchmarks Game is a sign that you've tried to jump to the answer without really taking enough time to understand the question.
[1]: https://blogs.msdn.microsoft.com/ricom/2005/05/10/performanc...
Re: Beating C with Dyalog APL
#20Pretty sure the words function can be simplified to {⍴(~⍵∊⍺)⊆⍵} (and it also handles empty strings).
How nice of you to copy/paste my reddit comment!