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

RISC-V J extension – Instructions for JITs

github.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: RISC-V J extension – Instructions for JITs

#41

Post by ghusbands »

blippage wrote: post #32
aidenn0 wrote: post #14

Earlier quoted context omitted.

The proper argument was always that optimizing compilers generate better assembly than 90% of the people using them could generate, and in a fraction of the time. However these things often get turned into stronger (or different) arguments as they pass from mouth to ear repeatedly. Sometimes they change completely, as in "the plural of anecdote is data"

I wanted to write a memcpy() routine for a microcontroller. I wrote a naive version where I copied from src to dst one byte at a time. You can find algorithms which are more efficient than this, which will typically copy 32 bit words at a time. The interesting thing is, I turned on compiler optimisations. When I examined the assembled output (even though my knowledge of assembly is poor), I discovered that it had mad…

Quite often, that doesn't end up very efficient, because without "restrict", the result has to be identical to what it would be if it was copied byte by byte, for all possible overlaps of the two inputs.

Re: RISC-V J extension – Instructions for JITs

#42

Post by blibble »

pjmlp wrote: post #33
adgjlsfhk1 wrote: post #29

Earlier quoted context omitted.

I'm honestly not sure why we haven't just admitted C isn't fixable.

Because that requires throwing away UNIX and many people feel quite strongly about it, given that it has won the data center wars. > C Language. Dialect ISO C. ISO C source programs invoking the services of this Product Standard must be supported by the registered product. -- http://get.posixcertified.ieee.org/docs/si-2016.html I should also note that many attempts to add safer types to C have been tried, WG14 just d…

ntoskrnl.exe is C too

Re: RISC-V J extension – Instructions for JITs

#43

Post by cbm-vic-20 »

mhh__ wrote: post #34
blippage wrote: post #32

Earlier quoted context omitted.

I wanted to write a memcpy() routine for a microcontroller. I wrote a naive version where I copied from src to dst one byte at a time. You can find algorithms which are more efficient than this, which will typically copy 32 bit words at a time. The interesting thing is, I turned on compiler optimisations. When I examined the assembled output (even though my knowledge of assembly is poor), I discovered that it had mad…

Even ignoring the usual optimizations like using SIMD and loop unrolling to find parallelism when doing memcpy, the compiler actually has techniques for spotting certain loop idioms so it can actually replace the loop with a memcpy library call if it deems it profitable (e.g. tell it it's likely to have N>bigNumber and it'll go for a library)

There are additional optimizations like using C's printf without any extra arguments, the compiler will replace that with a call to puts, which doesn't have the formatting code. You can see this in Compiler Explorer.

https://godbolt.org/z/dvdzE4M6T

Re: RISC-V J extension – Instructions for JITs

#44

Post by pjmlp »

blibble wrote: post #42
pjmlp wrote: post #33

Earlier quoted context omitted.

Because that requires throwing away UNIX and many people feel quite strongly about it, given that it has won the data center wars. > C Language. Dialect ISO C. ISO C source programs invoking the services of this Product Standard must be supported by the registered product. -- http://get.posixcertified.ieee.org/docs/si-2016.html I should also note that many attempts to add safer types to C have been tried, WG14 just d…

ntoskrnl.exe is C too

Not since Vista.

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-...

> Creates a binary that can be executed in the Windows kernel. The code in the current project gets compiled and linked by using a simplified set of C++ language features that are specific to code that runs in kernel mode.

And then there is WIL, https://github.com/microsoft/wil

https://community.osr.com/discussion/291326/the-new-wil-libr...

> First off, let me point out that this library is used to implement large parts of the OS. There are hundreds of developers here who use it. So unlike, uh, some other things that get tossed onto github, this project is not likely to wither and die tomorrow.

> There are, however, only a handful of kernel developers working on the library, so the kernel support has been coming along much slower. I'd like to expand the existing kernel features in depth ....

Re: RISC-V J extension – Instructions for JITs

#45

Post by blibble »

pjmlp wrote: post #44
blibble wrote: post #42

Earlier quoted context omitted.

ntoskrnl.exe is C too

Not since Vista. https://docs.microsoft.com/en-us/cpp/build/reference/kernel-... > Creates a binary that can be executed in the Windows kernel. The code in the current project gets compiled and linked by using a simplified set of C++ language features that are specific to code that runs in kernel mode. And then there is WIL, https://github.com/microsoft/wil https://community.osr.com/discussion/291326/the-new-wil-libr…

can explain how the existence of a compiler flag that allows third parties to compile C++ such that it can run in kernel means that the kernel has been rewritten in C++?

the fact LLVM allows javascript to be transpiled to C doesn't mean Linux kernel has been rewritten in Javascript

Re: RISC-V J extension – Instructions for JITs

#46

Post by hajile »

brucehoult wrote: post #39
fredoralive wrote: post #13

Earlier quoted context omitted.

Successful architectures seem to need a certain degree of pragmatism. ARM isn't exactly the RISCiest RISC, nor is AMD64 as baroque as the outer limits of CISC like iAPX 432. FJCVTZS is an example of pragmatism, the JavaScript spec says float to int should be done the way that x86 does it, the original ARM FCVTZS (no J) didn't do it the same way, but JavaScript is so important you have to add a special case. I hope I'…

To defend ARM (what? A RISC-V guy defending ARM?) there is absolutely nothing un-RISC about FJCVTZS. Every instruction set with floating point has some way to convert an FP value to an integer. FJCVTZS is no more complex than the existing FCVTZS -- it simply uses a different rounding mode and different behaviour if the value is too big. I don't know what you think RISC-V "compressed instruction" means. It's precisely…

> I don't believe there is any practical "magical" sequence of instructions that could be easily recognised to implement Javascript conversion from float to int. If that is in fact as important as ARM apparently think it is (I have my doubts) then an equivalent of FJCVTZS should be added to RISC-V as an extension.

They claim 2%, but only in JS code. I'd guess static analysis of outputted v8/JSC/SM JIT code from the top 100 websites would give a very accurate estimation of the savings. One of the most fundamental performance boosters is using 31-bit ints instead of doubles, but every single time time the user needs to access a number for output, it must be converted to a double to keep the JS spec contract.

All that said, I think only Apple's last 4-6 chips and ARM's most recent generation of chips actually implement the instruction and people have been fine without it. I'd guess we'll not be seeing this in RISC-V until much lower-hanging fruits have been picked.

Re: RISC-V J extension – Instructions for JITs

#47

Post by pjmlp »

blibble wrote: post #45
pjmlp wrote: post #44

Earlier quoted context omitted.

Not since Vista. https://docs.microsoft.com/en-us/cpp/build/reference/kernel-... > Creates a binary that can be executed in the Windows kernel. The code in the current project gets compiled and linked by using a simplified set of C++ language features that are specific to code that runs in kernel mode. And then there is WIL, https://github.com/microsoft/wil https://community.osr.com/discussion/291326/the-new-wil-libr…

can explain how the existence of a compiler flag that allows third parties to compile C++ such that it can run in kernel means that the kernel has been rewritten in C++? the fact LLVM allows javascript to be transpiled to C doesn't mean Linux kernel has been rewritten in Javascript

Apparently someone is lacking reading skills in how WIL is used on the kernel.

Re: RISC-V J extension – Instructions for JITs

#48

Post by blibble »

pjmlp wrote: post #47
blibble wrote: post #45

Earlier quoted context omitted.

can explain how the existence of a compiler flag that allows third parties to compile C++ such that it can run in kernel means that the kernel has been rewritten in C++? the fact LLVM allows javascript to be transpiled to C doesn't mean Linux kernel has been rewritten in Javascript

Apparently someone is lacking reading skills in how WIL is used on the kernel.

okay, so there exists a library that allows people to write C++ code that can be loaded into the kernel

this doesn't mean the ntoskrnl.exe is written in C++

the fact nvidia's linux loadable kernel blob is written in C++ doesn't suddenly mean linux is written in C++

"grasping at straws" would seem to sum up your position

Re: RISC-V J extension – Instructions for JITs

#49

Post by atq2119 »

sakras wrote: post #18
fredoralive wrote: post #13

Earlier quoted context omitted.

Successful architectures seem to need a certain degree of pragmatism. ARM isn't exactly the RISCiest RISC, nor is AMD64 as baroque as the outer limits of CISC like iAPX 432. FJCVTZS is an example of pragmatism, the JavaScript spec says float to int should be done the way that x86 does it, the original ARM FCVTZS (no J) didn't do it the same way, but JavaScript is so important you have to add a special case. I hope I'…

To be honest I kind of understand this “passing the buck”. In computing in general you never trust the guy up the stack to give you good input. Query engines do filter reordering because they don’t trust the optimizer to get it right. Compilers do optimizations because they don’t trust the programmer to get the order of operations right (rightfully). CPUs do OOO because they don’t trust compilers to get the order of…

> CPUs do OOO because they don’t trust compilers to get the order of instructions right.

Not really. CPUs do out-of-order because cache hits are unpredictable and it is crucial for single-threaded performance to make progress on dependent operations as soon as a loaded value is available.

There may be other, lower order, factors, but variable memory latency is the real reason.

Re: RISC-V J extension – Instructions for JITs

#50

Post by Sprite_tm »

ghusbands wrote: post #41
blippage wrote: post #32

Earlier quoted context omitted.

I wanted to write a memcpy() routine for a microcontroller. I wrote a naive version where I copied from src to dst one byte at a time. You can find algorithms which are more efficient than this, which will typically copy 32 bit words at a time. The interesting thing is, I turned on compiler optimisations. When I examined the assembled output (even though my knowledge of assembly is poor), I discovered that it had mad…

Quite often, that doesn't end up very efficient, because without "restrict", the result has to be identical to what it would be if it was copied byte by byte, for all possible overlaps of the two inputs.

Lots of memcpy() implementations are still more efficient than a dumb byte-by-byte copy. They'll copy the (unaligned) head and the tail in bytes, but the bulk of the data using whatever data type and method is fastest.
Post reply on HN