News for hackers. Stuff that matters.
Re:Making bracket pair colorization faster by Jensson on Wednesday September 29, 2021 @10:31AM (#28694157)
They talked about stack of libraries beneath you, not the execution stack. If an API call takes 10 microseconds because several "premature optimization is the root of all evil" abstractions in between then doing that just 10k times already nets you 100ms which is a very noticeable stutter. So with that limitation you are now forced to create elaborate data structures with caching etc to try to work around this slow API call. However doing the same querying in C++ without those abstractions where each call takes 10 nanoseconds means that you no longer have to try to create complex data structures to work around that slow API call, even if you do it a million times it would only take 10 milliseconds and maybe drop a frame.
Re:Making bracket pair colorization faster by npigrounet on Wednesday September 29, 2021 @06:31PM (#28700832)
Nowadays JS is as fast as C++, if not faster.
Re:Making bracket pair colorization faster by goldenkey on Wednesday September 29, 2021 @08:00PM (#28701587)
Let me respond for him. He meant abstraction as in "stack of dependencies." Because everyone knows that's what abstraction means, right?! Because we all know NPM is a disaster as opposed to C++ dependency management which doesn't even exist in a standard form. /s
Re:Making bracket pair colorization faster by Jensson on Thursday September 30, 2021 @03:49AM (#28704072)
Microsoft has a C++ API you use to make programs for windows. If you write in C++ you will code directly against that. If you write in Javascript then you will code against someone else's API that they wrote to interface with the Microsoft API. If you write in Javascript another step up then you will code your plugin against the VSCode API which then uses the Electrons wrapper around Microsofts API to do stuff, if there aren't more libraries in between. This stack of abstractions turned out to be too slow to solve the problem mentioned in the article we are talking about, so to solve it they moved the entire thing up one step in the stack.

In these situations it is common to have a problem that is really easy to solve but the API abstractions you have to work with doesn't support the operations at the speeds you need to solve it. If you have never experienced that then you aren't working on performance intensive projects where every bit counts and your input on this topic doesn't matter. I have worked on performance intensive libraries crossing programming language boundaries and the abstraction boundaries absolutely puts a limit on the amount of performance you can get. Well designed abstractions are less obstructive but plenty of them aren't well designed and even the well designed ones have overhead.

Re:Making bracket pair colorization faster by WorldMaker on Thursday September 30, 2021 @11:19AM (#28707364)
Microsoft has a COM API. C++ has a stack of macros and abstractions for communicating with a COM API. If you code in C++ you code in abstraction to an interface to the Microsoft API but not the API.

To get rid of abstractions you almost should be writing more directly in some sort of COM+ language.

(To explain the punchline for those that don't catch the joke: COM+ was the codename/early name of what became .NET.)

Re:Making bracket pair colorization faster by goldenkey on Friday October 01, 2021 @03:27AM (#28715645)
Microsoft has a COM API but when I used to develop, I'd just call kernel32, user32, advapi32, and other system C APIs directly. COM is a POS imo. DirectX is a decently engineered class-based API. But the rest of them have a lot of flaws.

The funny part is OP is talking all about uOPS when if he was really hardcore (like I am) he'd know that these dlls in turn call ntdll, many calls in ntdll are undocumented but much faster than their wrappers in the other dlls. But no sane person is going to strictly do ntdll calls except for the most performance critical code.

OP just doesn't know enough about C and C++, he probably grew up on C++ and forgot about the old C apis. I used to reverse engineer and delve deep into the windows API. I know a little bit more about performance than the average high level programmer.

And ultimately, .NET does a fine job with performance. C++ coders crapping all over .NET should take a look at the Objective C API of Apple. It's the default and every Objective C call incurs overhead and is basically a wrapper around the undocumented C API. But I don't think anyone ever complained about this abstraction, because it's such a stupid and small amount of performance to harp about. The convenience outweighs the tiny little uOPS loss.

Re:Making bracket pair colorization faster by goldenkey on Thursday September 30, 2021 @10:01AM (#28706414)
Ah, so this is all coming from a Microsoft C++ guy. Well better get to using those undocumented ntdll calls since you really need those uOps. It's not like the standard libraries of other languages is written in C or anything... ;-)
Re:Making bracket pair colorization faster by npigrounet on Thursday September 30, 2021 @08:08AM (#28705387)
JS is almost close to the metal nowadays thanks to the stunningly optimized JIT.
Re:Making bracket pair colorization faster by amw-zero on Friday October 01, 2021 @07:20AM (#28716972)
Can you initialize a kernel with JS?
Re:Making bracket pair colorization faster by goldenkey on Saturday October 02, 2021 @11:07AM (#28729142)
Of course. Have you not seen the VMs written in JS?

https://bellard.org/jslinux/

Re:Making bracket pair colorization faster by amw-zero on Saturday October 02, 2021 @03:10PM (#28731130)
That is a VM running in a web browser. If I was thinking about a joke that was so comically far away from the metal, that’s pretty much what I would use as an example.

This is why it’s very difficult to have conversations. Most programmers really don’t even know how computers work.

Re:Making bracket pair colorization faster by goldenkey on Wednesday October 06, 2021 @02:17PM (#28776339)
Heh, I know plenty about how computers work. You didn't specify what hardware you wanted targeted. Emulated devices are just abstractions.

Here is a real kernel: https://news.ycombinator.com/item?id=7958194

It's so difficult to have conversations with engineers that don't know x86 assembly. They never stop complaining. If only I could NOP them! ;-)