Tuesday, May 16, 2017

Digest for comp.lang.c++@googlegroups.com - 13 updates in 6 topics

fir <profesor.fir@gmail.com>: May 16 07:00AM -0700

W dniu wtorek, 16 maja 2017 06:31:08 UTC+2 użytkownik Chris M. Thomasson napisał:
 
> This was for masm. I have versions for gas as well:
 
> http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm
 
> http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html
 
dont look as too much pain to me
 
some pain in asm maight there be
linking (makin obj and linking also to system) and things like that, but today
i think c programmers knows linking well
so in fact a dose of easy assembly lik that above doesnt seem to be pain
 
though obviously today assembly would more usefull for study not for some much practical needs
"Chris M. Thomasson" <invalid@invalid.invalid>: May 15 09:31PM -0700

On 5/15/2017 8:36 PM, Lynn McGuire wrote:
> for the 386 since that compiler had jump near / medium / far issues.
> Lately, I have hand coded a few items in Assembler in our C++ code for
> security obfuscation. All terrible Assembler but it works.
 
Last time I wrote asm for some real work was back when I did not trust
the compiler to handle sensitive non-blocking algorithms. Here is a
taste of the pain:
 
http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html
 
http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-masm.asm
 
This was for masm. I have versions for gas as well:
 
http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm
 
http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html
 
I love the new C/C++!
legalize+jeeves@mail.xmission.com (Richard): May 16 08:34PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>> It is running a competition that will share $55,000 (£42,000) between
>> the top two people who can make its FUN3D software run up to 10,000
>> times faster.
 
Maybe useful to a student, but $55K for a 10,000x improvement seems
like woefully inadequate pay for what they are asking for.
 
Unless the software is horribly written to begin with, improving
things 5 orders of magnitude is usually not what you get from
optimization.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Christian Gollwitzer <auriocus@gmx.de>: May 16 11:48PM +0200

Am 16.05.17 um 14:42 schrieb Scott Lurndal:
> pretty straightforward to download and build most of the models. The
> vast majority of which are written in FORTRAN and use one of the parallelization
> features such as openMP or are in C/C++ and use CUDA.
 
So this was just another classic Jerry line with claimed expertise and
no real knowledge behind. Good to know.
 
Christian
fir <profesor.fir@gmail.com>: May 16 03:37PM -0700

W dniu wtorek, 16 maja 2017 22:35:07 UTC+2 użytkownik Richard napisał:
 
> Unless the software is horribly written to begin with, improving
> things 5 orders of magnitude is usually not what you get from
> optimization.
 
at least you could count the
needed bandwidth (in the case where you will get it 10k x faster)
if the needed bandwidth is more than present cpu gan give then you know the
people who stated that quests are sorta idiots (n00bs), if its less i think you may try ;c
Christiano <christiano@engineer.com>: May 16 06:42PM -0300

PPP2 stands for "Programming: Principles and Practices using C ++ 2nd edition"
 
There is an effort going on from volunteers who want PPP2 book programs running without problems and on other non-Windows systems, such as Linux.
You can see it here:
https://groups.google.com/forum/#!topic/ppp-public/BtlzdWGuQpQ
 
Now everything is working normally using gui2.tar.gz (on link above), however on page 432 the book presents a code similar to this:
 
------------begin main.cpp-----------------------------
#include "Simple_window.h"
#include "Graph.h"
 
int main()
{
using namespace Graph_lib;
 
Point tl {100,100};
Simple_window win {tl,600,400,"Canvas"};
 
Text t{Point{150,150}, "Hello, graphical world!"};
win.attach(t);
 
t.set_font(Font::times_bold);
t.set_font_size(20);
 
win.wait_for_button();
 
return 0;
}
------------end main.cpp-------------------------------
 
And the compiler shows the following error message:
 
-----------------begin Error message-------------------
main.cpp:14:13: error: reference to 'Font' is ambiguous
t.set_font(Font::times_bold);
^
/usr/local/include/X11/X.h:100:13: note: candidate found by name lookup is 'Font'
typedef XID Font;
^
./Graph.h:56:7: note: candidate found by name lookup is 'Graph_lib::Font'
class Font {
^
1 error generated.
*** Error code 1
-----------------end Error message---------------------
 
That is, PPP2 Graph_lib's "Font" is conflicting with Xorg's "Font".
 
I know how to fix:
 
------------begin main2.cpp-----------------------------
#include "Simple_window.h"
#include "Graph.h"
 
int main()
{
using namespace Graph_lib;
 
Point tl {100,100};
Simple_window win {tl,600,400,"Canvas"};
 
Text t{Point{150,150}, "Hello, graphical world!"};
win.attach(t);
 
t.set_font(Graph_lib::Font::times_bold);
t.set_font_size(20);
 
win.wait_for_button();
 
return 0;
}
------------end main2.cpp-------------------------------
 
I have just changed
from line:
t.set_font(Font::times_bold);
to
t.set_font(Graph_lib::Font::times_bold);
 
Making it clear that the Font is from the Graph_lib namespace.
 
But I would like to know if there is any way to make the program work without having to change the main.cpp program so that the original code was
preserved and consequently the code from book did not have to have a "special case". Any suggestion is welcome.
 
The Graph_lib + main2.cpp + my Makefile can be downloaded here:
http://35.167.12.56/program.tar.gz
Assuming FLTK lib installed in "/usr/local/" and C++ compiler command being "CC"
alexo <alessandro.volturno@libero.it>: May 16 09:43PM +0200

I've simplified the code removing the pointer but the message I get
compiling it is always the same
 
obj\Release\main.o||In function `main':|
class\main.cpp|13|undefined reference to `MyClass<int>::MyClass(int)'|
class\main.cpp|13|undefined reference to `MyClass<int>::~MyClass()'|
class\main.cpp|13|undefined reference to `MyClass<int>::~MyClass()'|
 
error: ld returned 1 exit status|
 
Build failed: 4 error(s), 0 warning(s) (0 minute(s), 0 second(s))
 
$ errors but the compiler doesn't tell me what they are. It shows only
linker errors.
 
 
btw this is the output of the compiler --version command
 
g++ (tdm-1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
what is the problem in my code?
 
 
#include <iostream>
#include <typeinfo>
#include <cstring>
 
using std::cout;
using std::endl;
 
/// the class' declaration
 
 
 
template <class T>
class MyClass
{
T data;
 
public:
MyClass(T);
MyClass(const MyClass<T> &);
~MyClass();
};
 
 
/// the class' definition
 
 
// constructor
 
template <class T>
MyClass<T>::MyClass(T val)
{
data = val;
}
 
// copy constructor
 
template <class T>
MyClass<T>::MyClass(const MyClass<T> &obj)
{
if( typeid(T) == typeid(char *) )
{
int len = strlen(obj.data);
strncpy(data, obj.data, len+1);
}
else
{
data = obj.data;
}
}
 
/// the main function
 
int main()
{
MyClass<int> test(3);
 
cout << test.data << endl;
 
return 0;
}
red floyd <dont.bother@its.invalid>: May 16 01:36PM -0700

On 5/16/2017 12:43 PM, alexo wrote:
 
> cout << test.data << endl;
 
> return 0;
> }
 
I'm not sure why you're getting the linker error on the constructor,
since it seems like you actually did define it, but the linker error
on the destructor is because you only declared it, but didn't define
it.
legalize+jeeves@mail.xmission.com (Richard): May 16 08:35PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>The free duct-tape-and-chewing-gum-based e-mail infrastructure for the
>moderation process, adopted after some University retired the original
>moderation servers, just stopped working.
 
I am willing to look at this infrastructure to see if it can be made
to work again.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 16 08:56AM +0200

On 16-May-17 8:48 AM, Adam Badura wrote:
> -----
> auto deduces here std::initializer_list as expected. What is not
> expected however is its value type. It is not int but const int!
 
That's not unexpected: it's required (for a `std::initializer_list`).
 
And yes it's a sometimes annoying limitation.
 
Still initializer lists are great. :)
 
 
Cheers!,
 
- Alf
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 16 06:46AM -0700

On Tuesday, May 16, 2017 at 9:27:06 AM UTC-4, Rick C. Hodgin wrote:
 
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
 
> I would appreciate a reference to where this happens, because to my
> current knowledge it does not automatically happen.
 
I see this on page 3709 of the manual linked above:
 
On the Intel486 processor, a write to an instruction in the cache
will modify it in both the cache and memory. If the instruction was
prefetched before the write, however, the old version of the
instruction could be the one executed. To prevent this problem, it
is necessary to flush the instruction prefetch unit of the Intel486
processor by coding a jump instruction immediately after any write
that modifies an instruction.
 
The P6 family and Pentium processors, however, check whether a write
may modify an instruction that has been prefetched for execution.
This check is based on the linear address of the instruction. If
the linear address of an instruction is found to be present in the
prefetch queue, the P6 family and Pentium processors flush the
prefetch queue, eliminating the need to code a jump instruction
after any writes that modify an instruction.
 
-----
NOTE
 
The check on linear addresses described above is not in practice a
concern for compatibility. Applications that include self-modifying
code use the same linear address for modifying and fetching the
instruction. System software, such as a debugger, that might possibly
modify an instruction using a different linear address than that
used to fetch the instruction must execute a serializing operation,
such as IRET, before the modified instruction is executed.
 
I don't see any references to describing what happens on more modern
architecture, only these notes regarding compatibility with prior
architectures (Pentium, Pentium Pro and derivatives).
 
On this website, I find a reference to more modern features, that it
will snoop the instruction cache and invalidate the pipeline:
 
http://blog.onlinedisassembler.com/blog/?p=133
 
... but that the express behavior is model-specific, and not an
inherent trait of the architecture which exists across all models in
the families.
 
Thank you,
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): May 16 02:44PM


>I don't see in the IA-32/Intel64 architecture manual where it says
>the pipeline will be flushed if it detects changes in the L1
>instruction cache:
 
Volume 3A:
 
"A write to a memory location in a code segment that is currently
cached in the processor causes the associated cache line (or lines)
to be invalidated. This check is based on the physical address
of the instruction. In addition, the P6 family and Pentium
processors check whether a write to a code segment may modify
an instruction that has been prefetched for execution. If the
write affects a prefetched instruction, the prefetch queue is
invalidated. This latter check is based on the linear address
of the instruction. For the Pentium 4 and Intel Xeon processors,
a write or a snoop of an instruction in a code segment, where the
target instruction is already decoded and resident in the trace
cache, invalidates the entire trace cache. The latter behavior
means that programs that self-modify code can cause severe
degradation of performance when run on the Pentium 4 and Intel Xeon processors."
 
 
>changes. The L1 instruction cache will be updated, but that will
>only affect the next pass through the code when a new set of load-
>and-decode operations takes place on those opcode bytes.
 
Besides being a performance killer, self-modifying code on non-intel
architectures requires flushing the instruction cache, which non-privileged
code may or may not be able to accomplish.
 
Just don't do it. Ever. The days of 4KW address spaces are long in the past.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 16 08:01AM -0700

On Tuesday, May 16, 2017 at 10:44:59 AM UTC-4, Scott Lurndal wrote:
> cache, invalidates the entire trace cache. The latter behavior
> means that programs that self-modify code can cause severe
> degradation of performance when run on the Pentium 4 and Intel Xeon processors."
 
I see similar language in section 11.6 of that manual on page 3090, but
it is only referring to operation of P6 and Pentium families. We are
several families beyond that generation now.
 
I do find this guidance for current architectures, with the warning that
SMC behavior is model-specific (page 2918), and one of the options it
suggests is the one mentioned above (to use a JMP instruction):
 
8.1.3 Handling Self- and Cross-Modifying Code
 
The act of a processor writing data into a currently executing code
segment with the intent of executing that data as code is called
self-modifying code. IA-32 processors exhibit model-specific behavior
when executing self modified code, depending upon how far ahead of
the current execution pointer the code has been modified.
 
As processor microarchitectures become more complex and start to
speculatively execute code ahead of the retirement point (as in P6
and more recent processor families), the rules regarding which code
should execute, pre- or post-modification, become blurred. To write
self-modifying code and ensure that it is compliant with current
and future versions of the IA-32 architectures, use one of the
following coding options:
 
(* OPTION 1 *)
Store modified code (as data) into code segment;
Jump to new code or an intermediate location;
Execute new code;
 
(* OPTION 2 *)
Store modified code (as data) into code segment;
Execute a serializing instruction; (* For example, CPUID instruction *)
Execute new code;
 
The use of one of these options is not required for programs
intended to run on the Pentium or Intel486 processors, but are
recommended to ensure compatibility with the P6 and more recent
processor families.
 
The option (1) that's there is that which this code in the video
codec may be doing.
 
> code may or may not be able to accomplish.
 
> Just don't do it. Ever. The days of 4KW address spaces are long
> in the past.
 
SMC is a requirement for true optimization. It is more of a startup
modification once the capabilities of the machine are assessed, but
you can minimize instruction cache pollution by dynamically altering
your code at runtime so that algorithms which won't be required in
this runtime instance are no longer present, etc.
 
It's tricky, but you'll never have performance which reaches to the
levels which use it, even if it's only an up-front modification, or
a first-pass modification, which does have the performance hit, but
from that point on it won't have a performance hint, and the new
optimizations now applied will result in fewer code bytes being
cached for the same algorithm, and more optimized code based on some
variations known about at compile-time, which could only be fully
expressed at run-time once the machine state was identified.
 
Thank you,
Rick C. Hodgin
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)