2 ms·

>I guess you can use tools like V-Tune for that. And I am saying you cannot. >What you mean by doing prefetchin C? There isn't any ANSI C feature for that. A

>I guess you can use tools like V-Tune for that. And I am saying you cannot. >What you mean by doing prefetchin C? There isn't any ANSI C feature for that. Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. >You can also do layout changes in Haskell, for example use a ByteString instead of Text, or an Array instead of Lists and so on. So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with.

pjmlp 10y ago
> Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. Which is a language extension and not a C feature. Nothing prevents an Haskell compiler to provide similar extensions. > So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with. Yeah, with my limited Haskell knowledge I would say you would need to make use of Data.Vector.Unboxed or use unboxed values as compiler extension like on JHC. Still, there are ways to improve performance on Haskell applications, even if they require new ways of thinking. Back in the day higher level languages (including C) were quite bad at generating code on home computers, and we had to use Assembly if we cared about performance. So like C compiler quality and tooling has improved in these last decades due to high industry use, Haskell tools can also improve if its acceptance in the industry keeps increasing. And then we can probably enjoy such tools for Haskell as well.
- pandaman 10y ago
  >Which is a language extension and not a C feature. In line assembler has always been C feature. I also fail to see the point of mentioning intrinsics being extension. Do you have an example of a compiler, which does not support cache prefetch on a platform that supports them? >I would say you would need to make use of Data.Vector.Unboxed I believe you are missing my point. The run-time layout of this type is not known in the first place. Making it unboxed may or may not change its layout to another unknown one. If you need a specific change, and not a change for the sake of change - there is nothing you can do. In C, I might want this to be a 12 byte type if I access the values sequentially and a 16 byte if randomly. In Haskell you can either have it boxed (and you have an order of magnitude more cache misses) or have either 12 or 16 byte in unboxed, but you cannot tell which one and if you wanted another one - tough cookies. >Haskell tools can also improve if its acceptance in the industry keeps increasing. And if they do we will discuss them then.
  - deleted 10y ago
    [deleted]

pjmlp 10y ago

> Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. Which is a language extension and not a C feature. Nothing prevents an Haskell compiler to provide similar extensions. > So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with. Yeah, with my limited Haskell knowledge I would say you would need to make use of Data.Vector.Unboxed or use unboxed values as compiler extension like on JHC. Still, there are ways to improve performance on Haskell applications, even if they require new ways of thinking. Back in the day higher level languages (including C) were quite bad at generating code on home computers, and we had to use Assembly if we cared about performance. So like C compiler quality and tooling has improved in these last decades due to high industry use, Haskell tools can also improve if its acceptance in the industry keeps increasing. And then we can probably enjoy such tools for Haskell as well.

pandaman 10y ago
>Which is a language extension and not a C feature. In line assembler has always been C feature. I also fail to see the point of mentioning intrinsics being extension. Do you have an example of a compiler, which does not support cache prefetch on a platform that supports them? >I would say you would need to make use of Data.Vector.Unboxed I believe you are missing my point. The run-time layout of this type is not known in the first place. Making it unboxed may or may not change its layout to another unknown one. If you need a specific change, and not a change for the sake of change - there is nothing you can do. In C, I might want this to be a 12 byte type if I access the values sequentially and a 16 byte if randomly. In Haskell you can either have it boxed (and you have an order of magnitude more cache misses) or have either 12 or 16 byte in unboxed, but you cannot tell which one and if you wanted another one - tough cookies. >Haskell tools can also improve if its acceptance in the industry keeps increasing. And if they do we will discuss them then.
- deleted 10y ago
  [deleted]