Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How is Ultrassembler so fast?

jghuff.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: How is Ultrassembler so fast?

#41

Post by Joker_vD »

mpyne wrote: post #33
aidenn0 wrote: post #20

Exceptions in C++ are never zero-overhead. There is a time-space tradeoff for performance of uncaught exceptions, and G++ picks space over time.

There's a time-space tradeoff to basically any means of error checking. Including checking return codes instead of exceptions. It's even possible for exceptions as implemented by g++ in the Itanium ABI to be cheaper than the code that would be used for consistently checking return codes.

Actually, there has been some research into building exceptions on the "basically, passing std::exception* into every function and checking what's inside it on every return" idea, and it was about as fast as the traditional table-based unwinding, took way less space in the executable, and re-throwing exceptions was actually faster [0][1]

[0] https://news.ycombinator.com/item?id=22483028

[1] https://www.research.ed.ac.uk/portal/files/78829292/low_cost...

Re: How is Ultrassembler so fast?

#42

Post by mpyne »

Joker_vD wrote: post #41
mpyne wrote: post #33

Earlier quoted context omitted.

There's a time-space tradeoff to basically any means of error checking. Including checking return codes instead of exceptions. It's even possible for exceptions as implemented by g++ in the Itanium ABI to be cheaper than the code that would be used for consistently checking return codes.

Actually, there has been some research into building exceptions on the "basically, passing std::exception* into every function and checking what's inside it on every return" idea, and it was about as fast as the traditional table-based unwinding, took way less space in the executable, and re-throwing exceptions was actually faster [0][1] [0] https://news.ycombinator.com/item?id=22483028 [1] https://www.research.ed.ac…

Yeah, it comes down to modeling assumptions on how many different types of exceptions can be thrown, how many actually are thrown, and the shape of the control flow graph of a program at runtime.

You can find one style outperforms the other based on the circumstances of the program, and programmers worried about optimization may someday be able to choose between approaches to meet their performance goals instead of pretending that tables are inherently slow and return codes that they won't even fully implement are inherently fast.

My point was simply that you can't just say "oh but exceptions are not zero-cost" without actually comparing to the alternative of laboriously carting return codes all through the call graph, as done in the research you show here and as also done by Khalil Estell elsewhere for ARM embedded.

Re: How is Ultrassembler so fast?

#43

Post by inetknght »

netr0ute wrote: post #7
inetknght wrote: post #4

Earlier quoted context omitted.

Overall, this is a fantastic dive into some of RISC-V's architecture and how to use it. But I do have some comments: > However, in Chata's case, it needs to access a RISC-V assembler from within its C++ code. The alternative is to use some ugly C function like system() to run external software as if it were a human or script running a command in a terminal. Have you tried LLVM's C++ API [0]? To be fair, I do think th…

> LLVM's C++ API I think I read something about this but couldn't figure out how to use it because the documentation is horrible. So, I found it easier to implement my own, and as it turns out, there are a few HORRIBLE bugs in the LLVM assembler (from cross reference testing) probably because nobody is using the C++ API. > There are plenty of cppcon presentations [1] about exceptions, performance, caveats, blah blah.…

> I don't have enough time to watch these kinds of presentations.

Then let me pick and share some of my favorites that I found enlightening, and summarize with some information that I found useful.

By far, the most useful one is Khalil Estell's presentation last year [0]. It's a fairly face paced but relatively deep dive into exception mechanics. At the end, he advocates for a new tool that would audit a program to determine what exceptions could be thrown. I think that's a flipping fantastic idea for a tool. Unfortunately I haven't seen any progress toward it -- if someone here knows where his tool is, or a similar tool, please reply! I did send him an email a few months ago inquiring about it, but haven't received a reply. Nonetheless, the whole presentation was excellent in my opinion. I did see that he had another related presentation at ACCU this year [4] with a topic of "C++ Exceptions are Code Compression" (which I totally can believe -- I've seen it myself in binary sizes), but I haven't seen his presentation yet. I'll watch it later today.

Just about anything from Herb Sutter is good. I don't like that he works for Microsoft, but he does great stuff for C++, including the old Guru of the Week series [1]. In particular, his 2019 presentation [2] describes different error handling techniques, some difficulties and pitfalls in combining libraries with different error handling techniques, and leads up to explaining why std::expected came about. He does pontificate a lot though, so the presentation is fairly high level and slow paced.

Dave Watson's 2017 presentation [3] dives into a few different implementations of stack unwinding. It's good to understand how different compilers implement exceptions with low- or zero-cost overhead and what that "overhead" is really measuring.

So, there's about a half of a day of presentations to watch here. I hope that's not too much for you.

[0]: https://www.youtube.com/watch?v=bY2FlayomlE

[1]: https://herbsutter.com/gotw/

[2]: https://www.youtube.com/watch?v=ARYP83yNAWk

[3]: https://www.youtube.com/watch?v=_Ivd3qzgT7U

[4]: https://www.youtube.com/watch?v=LorcxyJ9zr4

Re: How is Ultrassembler so fast?

#45

Post by jclarkcom »

Sesse__ wrote: post #39
jclarkcom wrote: post #38

Earlier quoted context omitted.

Windows uses memory mapped IO for loading all executable processes because it allows you to start executing a process after loading a few pages even if the exe is megabytes. You can use the same to reduce latency for starting to assemble data before the rest of the file loads, the rest can be loaded using more efficienct asynchronous mechanisms. Using for output also means your process doesnt waits on flushes that is…

Linux also uses mmap for running executables. But explicit I/O does not mean you have to start off by a gigabyte-long read().

More detailed explanation from ChatGPT. As quick estimate you could achieve a >2x speed up using memory mapped files for a typical assembler workload.

https://chatgpt.com/share/68b5e0db-a6d0-8005-9101-d326d2af0a...

Re: How is Ultrassembler so fast?

#46

Post by Sesse__ »

jclarkcom wrote: post #45
Sesse__ wrote: post #39

Earlier quoted context omitted.

Linux also uses mmap for running executables. But explicit I/O does not mean you have to start off by a gigabyte-long read().

More detailed explanation from ChatGPT. As quick estimate you could achieve a >2x speed up using memory mapped files for a typical assembler workload. https://chatgpt.com/share/68b5e0db-a6d0-8005-9101-d326d2af0a...

Why would anyone be interested in arguing against a confused AI?

Re: How is Ultrassembler so fast?

#47

Post by jclarkcom »

Sesse__ wrote: post #46
jclarkcom wrote: post #45

Earlier quoted context omitted.

More detailed explanation from ChatGPT. As quick estimate you could achieve a >2x speed up using memory mapped files for a typical assembler workload. https://chatgpt.com/share/68b5e0db-a6d0-8005-9101-d326d2af0a...

Why would anyone be interested in arguing against a confused AI?

I was trying to provide a more detailed explanation without typing a lot. I studied this problem a lot as PE at vmware.

Re: How is Ultrassembler so fast?

#48

Post by Sesse__ »

jclarkcom wrote: post #47
Sesse__ wrote: post #46

Earlier quoted context omitted.

Why would anyone be interested in arguing against a confused AI?

I was trying to provide a more detailed explanation without typing a lot. I studied this problem a lot as PE at vmware.

https://distantprovince.by/posts/its-rude-to-show-ai-output-...

In any case, if you really believe mmap is great for an assembler, then sure, go ahead. But it's not.

Re: How is Ultrassembler so fast?

#49

Post by jclarkcom »

Sesse__ wrote: post #48
jclarkcom wrote: post #47

Earlier quoted context omitted.

I was trying to provide a more detailed explanation without typing a lot. I studied this problem a lot as PE at vmware.

https://distantprovince.by/posts/its-rude-to-show-ai-output-... In any case, if you really believe mmap is great for an assembler, then sure, go ahead. But it's not.

I implemented an assembler as part of VMware thinapp and this was big performance boost for me but maybe you have a different experience from your efforts?

Re: How is Ultrassembler so fast?

#50

Post by Sesse__ »

jclarkcom wrote: post #49
Sesse__ wrote: post #48

Earlier quoted context omitted.

https://distantprovince.by/posts/its-rude-to-show-ai-output-... In any case, if you really believe mmap is great for an assembler, then sure, go ahead. But it's not.

I implemented an assembler as part of VMware thinapp and this was big performance boost for me but maybe you have a different experience from your efforts?

Yes. (I'm not going into a pissing contest.)
Post reply on HN