Topic: [neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin? - page 10. (Read 95279 times)

The shift to electronic money will be swift and physical currency will experience a waterfall collapse.

Go language:

I'm starting to have doubts about Rust's by-default emphasis on low-level control of memory allocation lifetimes and scopes:


The ability to compile to Javascript and moreover to be able to comprehend the Javascript produced (at least for the unoptimized output case) so it could be debugged with Javascript debuggers (e.g. in the browser) would certainly make a language much more accessible. I am thinking Rust's semantics are too heavy to ever achieve the latter. Minimizing required tooling could potentially remove some tsuris.

I like the Viᖚes name, I think it's cool.

Oh sure, I can't disagree when you state that you have defined requirements, done a diligent search and come up empty. (The above was mostly a response to AlexGR comments anyway.)

Now you just have to make a sound business case for building it, or if you can't do that then iterate your requirements.


Okay we mostly agree. The question is not only resources but also time to market (i.e. will the market wait?). This is not meant to suggest an answer.

There is no perfect language, but I told you already that I have certain requirements which my project dictates which are not met by any language:

1. JIT compilation as loaded over the Internet.
2. Strong typing with type parameter polymorphism, eager by default, with Top as the disjunction of all types and Bottom (_|_) as the conjunction of all types (Haskell is the opposite).
3. Async/await (stackless coroutines)
4. Haskell typeclass adhoc polymorphism, i.e. no subclassing which is an anti-pattern
5. Low-level control for performance with high-level elegance such as first-class functions and functional programming paradigm.
6. Add first-class disjunctions to #4.

There is no language on earth which can do that. My analysis thus far concludes Rust is closest.

Rust does everything except #3 and #6, and IMO its #4 and #5 need some polishing.

If you are just building an application, crypto-currency or just a website, then you don't need to invest in creating the correct tools. But when you are building an application platform for others to build on top of, then you have to invest in the tools. Ask Google about Android. Ask Apple about iOS.

Is it outside my resources? Maybe. That is what I am trying to determine now. Deep in research and coding.

I'm not even asking it to guess what is going to happen. It won't do it, even after profiling the logic and flow (monitoring the runtime - and recompiling after taking notes of the runtime that will be used for the PGO build).


What they are doing is primarily confining the use to arrays. If you don't use an array you are fucked (not that if you use arrays it will produce optimal code, but it will tend to be much better).

However, with AVX gaining ground, the losses are now not 2-4x as with leaving packed SSE SIMDs out, but rather 4-8x - which is quite unacceptable.

The spread between what your hardware can do and what your code generates in terms of result is increasing by the day. When you can group together 4 or 8 instructions in one, it's like your processor is not running at 4 ghz, but rather at 16ghz or 32ghz - as you want 1/8th the clock cycles for batch processing.

Contemplate this: In the 70s, "C is fast" meant something like we are leaving 5-10% on the table. Now it's gone up to 87.5% left on the table in an AVX scenario where 8 commands could be packed and batch processed, but weren't. Is this still considered fast? I thought so.


I can barely write programs, let alone compilers But that doesn't prevent me from understanding their deficiencies and pointing them out. I'm very rusty in terms of skills - I've not been doing much since the 90s. Even the asm code has changed two times from 16 bit, to 32 bit, to 64 bit...


Actually there are two-three additions in the form of #pragma that help the compiler "get it"... mainly for icc though. GCC might have ivdep.

AlexGR, assembly wouldn't regroup instructions to make them SIMD if you hadn't explicitly made them that way. So don't insinuate that C is a regression.

C has no sematics for SIMD, rather it is all inferred from what the invariants don't prevent. As smooth showed, that C compiler's heuristics are able to group into SIMD over loops but for that compiler and flag choices, it isn't grouping over unrolled loops.

Go write a better C compiler or contribute to an existing one, if you think that optimization case is important.

If you want explicit SIMD, then use a language that has such semantics. Then you can blame the compiler for not adhering to the invariants.

There was a chart (may or may not still be there) on the Dash website showing up to 50% per annum returns since I think the rate increases every year of being staked or something like that.

Please reply in the original thread (that my prior post was quoted from) and not here. I will delete my reply here and your post shortly, so please copy it to where it should go.

As I explained the key distinction upthread, those are free markets because they are decentralized and there is no significant asymmetry of information which makes it otherwise.

It pisses me off when readers waste my expensive time by ignoring what I already wrote twice in this thread. This makes three times. Please readers don't make me teach this again by writing another post which ignores my prior points.



1. I already provided the link to the thread two or three times in this thread, which explains that ICOs sold to non-accredited USA investors are ostensibly illegal.

I hate ICOs by now for other reasons:

2. They contribute to the mainstream thinking that crypto-currency is a scam and thus we will have great difficulty getting CC widely adopted if don't put a stop to these scams.

3. They extract capital to a few scammers, which could be better used to build our real ecosystems which are not vaporware and have real decentralized designs, such as Bitcoin and Monero.

4. They prey on the ignorance of n00b speculators, thus can never be a free market.

5. They can never attain adoption because they destroy the Nash equilibrium and decentralization of the ecosystem:




6. Because they are not decentralized and rely on expectation of profits based on the performance of a core group, ICOs turn what should be a competition for creating the best technology into a fist fucking fest of ad hominem and political games:


7. ICOs have less liquidity because they are not widely distributed and due to #5:

Superoptimizers are totally impractical in most cases. They are useful for small bits of frequently reused code (and yes in some cases probably want different sequences for different hardware variants). The point of bringing it up is simply to say that general purposes compilers don't and can't do that.

The thing with superoptimizers is that they might work differently on same instruction sets but different cpus.

Say one cpu has 32k l1 cache and another has 64k l1.

You can time all possible combinations in a 32k processor and it might be a totally different combo to what a 64k l1 processor need. The unrolling and inlining may be totally different, as can be the speed of execution in certain instructions where a cpu might be weaker.

So what you need is to superoptimize all profiles for all cpus, store these cpu-data-paths and then, on runtime, perform a cpu id check and execute the right instruction-path for that cpuid.

As for the


Let me just add that if you go over at john the ripper's site, it has like support for dozens of ciphers. People, over there, are sitting and manually optimizing these one by one because optimizations suck. The c code is typically much slower. This is not "my" problem. It's a broader problem. The fact that very simple code can't be optimized just illustrates the point. You have to walk before you can run. How will you optimize (unprunable) complex code if you can't optimize a few lines of code? You won't. It's that simple really.

Yes but that was not part of the original promise (your words: "When C was first created, it promised ..."). The original promise was something close to the hardware (i.e. C language operations mapping more or less directly to hardware instructions).

On the merits of the optimizations, you're still looking at one particular program, and not considering factors such as compile time, or how many programs those sorts of optimizations would help, how much, and how often.

If you look at any credible benchmark suite, for compilers or otherwise, it always consists of a large number of different programs, the test results of which are combined. In the case of compiler benchmarks, compile time, memory usage, etc. are among the results considered.

Anyway feel free to rant. As you say it is easy to whine when you are expecting someone else to build the compiler. And that is my point too.

Also, if you want optimal code (i.e. optimal use of hardware instructions) you do need a superoptimizer, even if you have profiling information. The original superoptimziers only worked on simple straight line code where profiling is irreverent. They may be slightly more flexible now, I'm not sure. Anyway, profiling is not the issue there.

I'll not reply again unless this gets more interesting, it is repetitive now.

The optimizations added later, were made possible by more complex code that could be simplified (=unnecessary complexity getting scaled down) plus the increase of usable ram.

For example if an unrolled loop was faster than a rolled one, or inlining worked better but cost you more memory (that you now had), it was worth it. But up to an extent (again) because now we have the performance-wall-limits of L1 and L2 cache sizes which are ...of 1970's main ram sizes

But in terms of instruction set utilization it's a clusterfuck. In a way we don't even need superoptimizers when we have PGOs for things that have been sampled to run in a predetermined way. You allow the compiler to see PRECISELY what the program does. No "if's" or "hows". It KNOWS what the program does. It KNOWS the logic and flow. It saw it running.

You (as a compiler) are allowed to see the executable doing

b=b/g
bb=bb/g
bbb=bbb/g
bbbb=bbbb/g

...and you now know that you can pack these 4 into two SIMDs. You didn't even have to see it running, you knew that these were different variables, with different outcomes. You knew they were aligned to the correct size. But even if you had any doubts, you even saw them running anyway with the -fprofile-generate. And still you are not packing these fuckers together after -fprofile-use. And that's the point where I'm furious about.

It's just a few simple "if then else" in the heuristics. IF you see instructions that can be packed THEN FUCKING PACK THEM instead of issuing serial scalar / SISD instructions. With AVX the loss is not 2-4x, but 4-8x. It's insane.

You don't need to know much about compilers to understand that their optimizations suck. You just see the epic fail that their PGO is and you know how bad heuristics they have, where they can't even tell what can be optimized by knowing full well the flow / logic / speed / bottlenecks, etc of the program.

I'm kind of repeating myself over and over for emphasis, but we need to realize that at the point where the profiler knows what the program does, there is no excuses left of the type "but, but, but I don't know if that optimization is safe so I can't risk it". No, now you know. With 100% certainty. (Not that packing 2 into 1 was risky).

If you look at the basic C operations, they all pretty much correspond to a single (or very small number) CPU instruction from the 70s. As TPTB said, it was pretty much intended to be a thin somewhat higher level abstraction but still close to the hardware. Original C wasn't even that portable in the sense that you didn't have things like fixed size integer types and such. To get something close to that today you have to consider intrinsics for new instructions (that didn't exist in the 70s) as part of the language.

The original design of C never included all these highly aggressive optimizations that compilers try to do today, that was all added later.  Back in the day, optimizers were largely confined to the realm of FORTRAN. They succeed in some cases for C of course, but its a bit of square peg, round hole.

Basically that brings up back to the starting point... When C was first created, it promised to be very fast and suitable for creating OS'es, etc. Meaning, its compiler wasn't leaving much performance on the table. With khz of speed and few kbytes of memory there was no room for inefficiency.

Granted, the instruction set has expanded greatly since the 70's with FPUs (x387), MMX, SSE(x), AVX(x), AES, etc, but that was the promise. To keep the result close to no overhead (compared to asm). That's what C promised to be.

But that has gone out the window as the compilers failed to match the progress and expansion of the cpu's arsenal of tools. We are 15 years after SSE2 and we are still discussing why the hell isn't it using SSE2 in a packed manner. This isn't normal for my standards.


Yes, it's somewhat better but not what I expected. That was in version 12 IIRC. Now it's at 15 or 16, again IIRC. I've actually used clang, icc, amd open64 - they don't have any serious differences. In some apps or cracking stuff, they might. I've seen icc excel in some crypto stuff.


We need a better GCC in general. But that's easy asking when someone else has to code it.

Compilers are not superoptimizers. They can't and don't promise to do everything a processor is capable of.


Maybe, maybe not. It just apparently hasn't been a priority in the development of GCC. Have you tried icc to see if it does better for example? (I don't know the answer.)

It is quite possible that an effort to improve optimization in GCC for the purposes of, for example, cryptographic algorithms would bear fruit. Whether that would be accepted into the compiler given its overall tradeoffs I don't know.

Yes, the streaming argument is valid, but the processor is capable of more than that.

I guess I'm asking too much when I want the compiler to group in a SIMD, similar but separate/non-linear (=safe) operations.

The comparison is not against some compiler that exists in fantasy land, but with real-life asm improvements.

How many cryptographic functions, mining software etc, aren't tweaked for much greater performance? Why? Because the compilers don't do what they have to do.

For example, what's the greatest speed of an sha256 for c and what's the equivalent in c+asm? I'd guess at least twice as fast for the later.

You can get the same results using pointers. Remember, SSE is Streaming SIMD extensions. It intended for processing large data sets. As it turns out the instructions can be used in scalar mode in place of regular FP instructions, and that appears advantageous, but you should never expect a compiler to produce optimal code. It is impossible.

The only truly meaningful evaluation of a compiler is against another compiler, or if you are a compiler developer, comparing the overall effects of having some optimization (across a large input set) against not having it. Comparing against some fantasy optimal compiler is dumb.

Yeah, the golden brackets of SIMDs... compilers love those, don't they? But they are rarely used if one isn't using arrays.

If my loop was

for 1 to 500mn loops do

b=b/g
bb=bb/g
bbb=bbb/g
bbbb=bbbb/g

...it wouldn't use any packed instructions.

Btw, if I made it 100mn loops x 4 math operations, as the original spec was intended (I did 4 ops x5 times the maths in every loop to compensate for fast finishing speeds - but apparently I won't be using them now with values like 2.432094328043280942 as it goes up to 20+ secs instead of 2), then I'd have to manually unroll the loop and lower the loop count and create arrays. Why? Because without those golden brackets the compiler is useless. You have to write, not as you want to write, but as the compiler wants you to write.