I really hate when....

[LordAdef]

I really hate when I decide to do some compression and optimization, spend some good time on it, only to realize that, after timming it, the bloody thing got actually slower :icon_redface: :icon_redface:


The good thing is I understand that bit of code a lot better.




This is also to say hello to my old friends, here!

[aw27]

Viva Bolsonaro  :t

The end of the corrupted PT era, restoration of traditional values.  :t

[jj2007]

Viva Bolsonaro  :t

Martin Niemöller:

"When the Nazis fetched the communists,
I kept silent;
I was not a communist.

When they imprisoned the Social Democrats,
I kept silent;
I was not a social democrat.

When they got the unionists,
I did not protest;
I was not a trade unionist.

When they brought the Jews,
I kept silent;
I was not a Jew.

When they got myself
there was no one left to protest."

[mineiro]

Viva Bolsonaro  :t

What was Hitler's political party?
Why do not I see flags of Germany instead of swastikas?
The ideological bias of Nazism is based on what ideology? Fascism of Italy?

Lenin:

"Impeach opponents of what you do, call them what you are!"

edit--- a better translation.
Judge them for what you are, criticize them for what you do

[aw27]

Venezuela Next! (click the image)!

[FORTRANS]

Hi,

I really hate when I decide to do some compression and optimization, spend some good time on it, only to realize that, after timming it, the bloody thing got actually slower

   Yes, compression, making programs smaller, and optimization,
making programs faster usually conflict.  Most of my attempts
with my code were to make things faster.  I have a generally poor
record of trying to make things smaller.  In either case it can be
hard to follow the 15% rule.

The good thing is I understand that bit of code a lot better.

   Yes, that is a useful side effect.  Sometimes the most useful
result.  On one program I wanted to speed up I tried everything
that I could find to speed it up.  On the intended platform I did
get it twice as fast.  On the computer where it was already too
fast, I got a 30X improvement.  But I did learn what kind of code
changes were likely to help, and which ones were likely to be a
waste of time.

This is also to say hello to my old friends, here!

   Well, hello back.  Nice to see you again.

Cheers,

Steve N.

[mineiro]

In Venezuela they are killing their own dogs to eat meat.

I really hate to see these things, and worse, to know that people have not understood about the past.

I have read the two government plans of the presidential candidates, and I leave it to you to compare with the past:
Who is in favor of mass extermination of people, I mean, abortion?
Who has the proposal of disarmament, create a new Constituent Assembly, regulate the press?
Prisons in Brazil are not to take the bandit out of society, but to re-socialize it. The villain's family receives more than one minimum wage, the honest worker's family and killed by the villain gets nothing.
Who wants more State in our lives, create new Ministries, plus taxes?

That's why I stopped commenting.

[jj2007]

compression, making programs smaller, and optimization, making programs faster usually conflict.

Often they do, but not as a general rule. Bloated code pollutes the execution cache, too. But it is true that using somewhat longer instructions, especially SIMD, can give much more speed than ultra compact slow old instructions such as lodsb & friends. Still, I use them often, e.g. when parsing for a filename inside a path. Since I rarely do that a Million times per second, it really doesn't matter speedwise.

[FORTRANS]

Hi Jochen,

Often they do, but not as a general rule.

   Okay, I will cede you this.  The difference between "usually"
and "often" is perhaps smaller than "a rule" though.  And my
experience is with my own code usually.

Bloated code pollutes the execution cache, too. But it is true that using somewhat longer instructions, especially SIMD, can give much more speed than ultra compact slow old instructions such as lodsb & friends.

   Unfortunately, the example I referred to was a program that
was intended for an 80186.  SIMD and cache concerns were
not applicable.  Code bloat was perhaps worse in that situation
though.  The newer computers reacted much better, to just
about every improvement I tried, than on the '186.

   Oh well, maybe next time I'll say something useful.  Something
like; profile your own code to see what happens.

Regards,

Steve N.

[felipe]

  Hey fortrans, it's actually very interesting to know someone in this world who actually programmed for a 80186... :icon14:

[aw27]

Hey fortrans, it's actually very interesting to know someone in this world who actually programmed for a 80186... :icon14:

I had a notebook powered by a NEC V20 which, quoting wikipedia, was a reverse-engineered, pin-compatible version of the Intel 8088 with an instruction set compatible with the Intel 80186. Operating System from factory was MSDOS 3.3. I think I have used it also with MSDOS 5.0, DRDos and other clones.
I have not thrown it away, one of these days I will look for it and see if it still works. It had a 1200 baud modem and I used it to connect to the BBSs I was selling software, namely V860 a relative success in the country pushed by some free press articles and interviews (in those times that could happen for free).

[LordAdef]

politics first:
Thanks AW, JJ and Mineiro
Well, I'm definitely not part of this debate. I don't vote for principle. It's outrageous that one is obliged by law to vote (which is a Right). The only decent country on earth that voting is still obliged by law is Australia (at least by wikipedia) (in Turkey too)
I hope we get good things done and this country gets back to track.

[LordAdef]

Hi,

I really hate when I decide to do some compression and optimization, spend some good time on it, only to realize that, after timming it, the bloody thing got actually slower

   Yes, compression, making programs smaller, and optimization,
making programs faster usually conflict.  Most of my attempts
with my code were to make things faster.  I have a generally poor
record of trying to make things smaller.  In either case it can be
hard to follow the 15% rule.

The good thing is I understand that bit of code a lot better.

   Yes, that is a useful side effect.  Sometimes the most useful
result.  On one program I wanted to speed up I tried everything
that I could find to speed it up.  On the intended platform I did
get it twice as fast.  On the computer where it was already too
fast, I got a 30X improvement.  But I did learn what kind of code
changes were likely to help, and which ones were likely to be a
waste of time.

This is also to say hello to my old friends, here!

   Well, hello back.  Nice to see you again.

Cheers,

Steve N.

Hi Steve! Hi JJ!Both nice contributions, I thank you both.
It's an interesting topic. I learned an awful lot from this experience. And now know how to work around it. The simple fact of changing to algorithms/code gave me a different perspective on how to optimize it further. And I did clean a lot of slow down code.
There is no reason to code in asm if you don't target for speed, right?I'm also plotting my benchmarks, and that is also being very very useful. Just boring to copy/paste it in OpenOffice. I not arsed to code a plotting routine, but may eventually do it in the end.

[felipe]

There is no reason to code in asm if you don't target for speed, right?

Actually that's not right... ;)

[LordAdef]

There is no reason to code in asm if you don't target for speed, right?

Actually that's not right... ;)

Well, you are right! Asm is a beautiful language apart from what I meant.